Skip to Content.
Sympa Menu

freetds - Re: [freetds] Handling type, new and old

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddy77 AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Handling type, new and old
  • Date: Mon, 20 Jan 2014 18:03:54 +0000

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 <msabramo AT gmail.com>:
> 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 <freddy77 AT gmail.com> wrote:
>
>> 2014/1/20 Frediano Ziglio <freddy77 AT gmail.com>:
>>> 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
>> FreeTDS AT lists.ibiblio.org
>> http://lists.ibiblio.org/mailman/listinfo/freetds
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds




Archive powered by MHonArc 2.6.24.

Top of Page