freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- 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
-
[freetds] Handling type, new and old,
Frediano Ziglio, 01/20/2014
-
Re: [freetds] Handling type, new and old,
Frediano Ziglio, 01/20/2014
-
Re: [freetds] Handling type, new and old,
Marc Abramowitz, 01/20/2014
-
Re: [freetds] Handling type, new and old,
Frediano Ziglio, 01/20/2014
-
Re: [freetds] Handling type, new and old,
Marc Abramowitz, 01/20/2014
-
Re: [freetds] Handling type, new and old,
Stephen Marshall, 01/20/2014
- Re: [freetds] Handling type, new and old, Frediano Ziglio, 01/21/2014
-
Re: [freetds] Handling type, new and old,
Stephen Marshall, 01/20/2014
-
Re: [freetds] Handling type, new and old,
Marc Abramowitz, 01/20/2014
-
Re: [freetds] Handling type, new and old,
Frediano Ziglio, 01/20/2014
-
Re: [freetds] Handling type, new and old,
Marc Abramowitz, 01/20/2014
-
Re: [freetds] Handling type, new and old,
Frediano Ziglio, 01/20/2014
Archive powered by MHonArc 2.6.24.