FreeTDS Development Group

[Marc Abramowitz <msabramo AT gmail.com>]

What do you mean by "half way supported"? (I think pymssql might not be
taking advantage of whatever support is there).

Love the idea of creating a framework that makes it easier to add types.
Clearly it's difficult to add a type with the current system, so if it can
be made more straightforward, that is a great step!


On Mon, Jan 20, 2014 at 10:03 AM, Frediano Ziglio <freddy77 AT gmail.com>wrote:

> 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
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>