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

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.  

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?  

HTH.  

--jkl