freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
- To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
- Subject: [freetds] Big patch...
- Date: Mon, 2 Jul 2007 09:19:38 +0200
I'm just merging this big patch.
It improves token handling adding the concept of column label in
addition to column name. Cursors need to distinguish between the two
concepts. Assuming a query like "select x as y from mytable" x is the
column name while y is the column label. To complicate everything the
protocol does not always return both column name and column label.
Issuing a normal query like the above server usually return just the
column label while using cursors, "for browse" clause or recent Sybase
products server returns both. Also I start using DSTR structure in
TDSSOCKET instead of arrays. The reason is mainly cause the arrays was
quite large but not that sufficient... assuming different encoding for
instance would lead table_name to be quite big.. 4 (components) * 128
(maximun component length) * 4 (maximun byte per characters) plus some
additional bytes (dots and quotes) would lead to 2kb !!! Quite big for a
string that usually occupy just some tenth bytes... So at the end I used
DSTR for column_name, table_name and column_label (new). Also you will
note that in code now I use mostly column_label and not column_name (the
reason was explain some rows above). Perhaps some code needs to be
changed from column_label to column_name but currently the situation is
quite conservative.
If nobody complaints I'll merge this work in a couple of days...
freddy77
Attachment:
vedi.diff.gz
Description: vedi.diff.gz
-
[freetds] Big patch...,
ZIGLIO, Frediano, VF-IT, 07/02/2007
-
Re: [freetds] Big patch...,
James K. Lowden, 07/02/2007
- Re: [freetds] Big patch..., ZIGLIO, Frediano, VF-IT, 07/02/2007
- Re: [freetds] Big patch..., Frediano Ziglio, 07/03/2007
-
Re: [freetds] Big patch...,
James K. Lowden, 07/02/2007
Archive powered by MHonArc 2.6.24.