Re: Handling type, new and old

Well... at least DATE/TIME are half way supported. Tables are
completely not supported.
By the way... do you like my idea/proposal?

Frediano

2014/1/20 Marc Abramowitz <[email protected]>:
> 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
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds