Re: Handling type, new and old

Or another example is DATE and TIME. 

Periodically, pymssql users ask why they can use a Python datetime but not a date or time. 

I would guess this questions comes up for other language bindings too. 

-Marc
http://marc-abramowitz.com
Sent from my iPhone 4S


On Jan 20, 2014, at 7:51 AM, Frediano Ziglio <[email protected]> wrote:

> 2014/1/20 Frediano Ziglio <[email protected]>:
>> Hi,
>>  as discussed recently adding a new type to libTDS is quite a nightmare!
>> 
>> I was thinking a different way to handle our types. Mainly something
>> similar to functions pointers we have but extended so support
>> everything. I would like to extend it in a way that every upper
>> library could have additional "methods" specific to this library.
>> However I want to not have to code of a specific library in libTDS.
>> libTDS should be able to get the table of a specific type with the
>> extended information and call method it needs. Only upper layer will
>> see additional methods. I'd like that when a new type is added to
>> libTDS compilation of upper layer will fail until type is correctly
>> supported. Also I'd like something that does not require many
>> allocation but I would prefer statically allocated structures. My
>> implementation idea is this:
>> 
>> libTDS has an array of pointer to structures indexed by type to the
>> function pointers, something like:
>> 
>> struct tds_type_pointers type_funcs[] = {
>>   ...
>>   funcs_chars,
>>   ...
>>   funcs_int,
>> };
>> 
>> Now, libTDS will provide implementations for functions but NOT for the
>> structures. That way to avoid link failures upper layers has to
>> provide the structures, better if they extend them. So for instance
>> ODBC could define an extended structure
>> 
>> struct odbc_type_pointers {
>>    tds_type_pointers common;
>>    unsigned (*get_sql_type)(TDSCOLUM *col);
>> };
>> 
>> ...
>> 
>> struct odbc_type_pointers funcs_chars = {
>>    { tds_char_get, ...},
>>    odbc_get_char_sql_type;
>> }
>> 
>> Does we agree on doing that. Probably it will require some changes (a
>> lot) but adding a new type will be very easy! Probably will require
>> some additional macro and a lot of definitions but beside that we
>> avoid to miss some pieces.
> 
> Some example why. Let's assume libTDS wants to add a new type. For
> instance libTDS does not handle tables (yes, mssql 2012 can return a
> table as a type!). We add a declaration (but NO a definition) for a
> funcs_table. Now we try to compile and links fails as linker does not
> fund funcs_table definition (actually it fails in dblib, ctlib and
> odbc). We have to define funcs_table in every upper library.
> 
> Frediano
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds