Re: Handling type, new and old

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