Skip to Content.
Sympa Menu

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

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] db-lib: support for new MS SQL 2008 data types - part 3
  • Date: Fri, 18 Apr 2014 17:27:45 -0400

On Fri, 18 Apr 2014 09:26:03 +0100
Frediano Ziglio <freddy77 AT gmail.com> 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




Archive powered by MHonArc 2.6.24.

Top of Page