FreeTDS Development Group

["ZIGLIO Frediano" <Frediano.Ziglio AT vodafoneomnitel.it>]

> 
> I spent quite a bit of the weekend going over bcp.c tracking down
> UTF-8 issues.  I noticed that BCP_COLINFO functionally duplicates
> TDSCOLINFO, making the code harder (for me at least) to understand. 
> More important, as TDSCOLINFO info changes to support iconv, those
> same changes are going to have to be re-invented in BCP_COLINFO.  
> 
> It would be nice IMO if someone had the time to rip out BCP_COLINFO
> and replace it with TDSCOLINFO.  If nothing else, I'll do that when I
> migrate bcp.c from db-lib to libtds, in preparation for blk-lib use.
> (I also think the "column_" prefix should go.)   
> 
> Here's my analysis of the two structures.  
> 
> BCP_COLINFO   TDSCOLINFO      
> tab_colnum

Perhaps this info will be useful in TDSCOLINFO too (think at SELECT ... FOR 
BROWSE)

> db_type               column_type
> db_length     column_size
> db_nullable   column_nullable
> data          column_offset   // semantically different

?? I don't know bcp very well... what difference ?

> data_size     column_cur_size
> db_usertype   column_usertype
> db_flags      column_flags
> db_type_save  on_server.column_type
> db_prec               column_prec
> db_scale      column_scale
> db_collate    column_collation
> db_name               column_name
> db_varint_size        column_varint_size
> 
> db_name               column_name
> db_minlen     // not used     
> db_maxlen     // not used     
> db_colcnt     // not used     
> db_status     // not used     
> db_offset     // not used
> db_default    // not used     
> db_size               // not used     

So, they should be removed...

> txptr_offset  column_textpos
> 

No, it's not the same. txptr is stored in data, column_textpos has another 
meaning.

> As you can see, BCP_COLINFO has many fields not in TDSCOLINFO, but
> only one of these is used.  
> 
> I also noticed that DBPROCESS::bcp_columns is an array of pointers to
> BCP_COLINFO structures.  It turns out, however, that we always know
> how many columns there are, so we could allocate an array of structs
> directly, gaining some efficiency and losing one level of
> indirection.  
>       
> For completeness, here are the TDSCOLINFO members not represented in
> BCP_COLINFO:  
> 
> column_namelen

Required if we plan to output UCS2/4 too...

> on_server.column_size
> table_namelen
> table_name

> column_writeable
> column_identity

Flags...

> column_output

???

> column_operator
> column_operand

compute infos

> column_bindtype
> column_bindfmt
> column_bindlen
> column_nullbind
> column_varaddr
> column_lenbind

These fields should be changed (when ZeroCopy will be implemented), libTDS do 
not use them...

> column_text_sqlgetdatapos
> 

Ugly (used only in ODBC) !!!

Many library require to extend this structure so they allocate another array 
with additional information. Perhaps extendind TDSCOLINFO and use pointer to 
extended column infos (like inheritance in OOP) is another idea (intead of 
removing a level of indirection use it)...
Just define some callback (alloc_column/free_column in TDSSOCKET) and use it.

Just to save other byte. ICONVINFO is huge. Instead of copy names use pointer 
to static data.

bye
  freddy77