Re: db-lib: support for new MS SQL 2008 data types - part 3

2014-04-18 22:27 GMT+01:00 James K. Lowden <[email protected]>:
> On Fri, 18 Apr 2014 09:26:03 +0100
> Frediano Ziglio <[email protected]> wrote:
>
>> Well... all these looks quite paranoid but external ABI needs to stay
>> so is better to decide what to stick into the dbdata structure!
>> date: perhaps would be better to just store the number from wire
>> (converted to 32 bit) without bias;
>> time: perhaps would be better to just store the number from wire
>> time_spec: use 3 bit instead of 4 ? We just need a range from 0 to 7.
>> Another idea could be to use a single byte instead and separate all
>> other flags. As compiler usually reserve bits from the bottom and as
>> this bitfield is the first is much easier for the cpu to extract this
>> number. Personally I would keep the bitfield reducing to 3 bits.
>> has_time, has_date and has_offset: they are fine. The only change I
>> would insert a TDS_USMALLINT _res:10 before. In such was all the
>> single bits will occupy the top position leaving space for extensions.
>> Order of the fields are optimized to reduce structure size.
>
> If I could chime in here, I don't understand all the sturm und drang
> over this type. You need a wire-image type, no matter how ungainly.  If
> it's three bytes, it's three bytes.  Return those three bytes as-is from
> dbdata. Write converters to other types that are easier to use.  Maybe
> define macros to make the bits easier to interpret in situ.
>

Date (3 bytes) would be the easier. Time is not fixed (from 3 to 5
bytes depending on precision), it's more like numeric where
TDS_NUMERIC is not exactly the wire representation. If we would just
stuck with wire tds_convert would require the scale/precision (in case
of time just the precision).

> Every SYB type maps to a DB type (e.g. SQLINT, DBINT).  Why mess with
> that?  Just extend it.  Define a struct that more conveniently
> represents the new date type; probably you want to mimic whatever
> Microsoft does for ODBC.  Won't anything else just mean more work?
>

Well, for INT is really easy, wire has the exact representation and
there is not even the need for a structure. I never though about ODBC
directly in libTDS, always wanted to be more upper layer independent.
ODBC introduced a new type for each introduced type (4). One main
reason for TDS_DATETIMEALL was make easier to handle all date/time
conversions in libTDS. Having to support 8 different structures (not
considering precision) and being able to convert freely from them give
more or less 64 combinations. The best way was to use a format that
could represent all date/time without losing any precision. Well..
this is perhaps an excuse as could be just an internal structure used
only by tds_convert.
Yes, ODBC way could be another solution to try. This would make
conversions a bit harder but surely ODBC code much easier and dbdata
would be easy too.

> HTH.
>
> --jkl

Frediano