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: Marc Abramowitz <msabramo 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 08:57:22 -0800

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




Archive powered by MHonArc 2.6.24.

Top of Page