FreeTDS Development Group

[Brian Bruns <camber AT umcc.ais.org>]

I've roughed in some support for numerics in dblib, but before I get too
far with it, I wanted to get some feedback. 

The way the implementation is working is that precision and scale are
stored in the TDSCOLINFO structure in the tds_process_results() function.
The problem is that although the information is there, dblib and ctlib
have structures that include precision, scale, and the value that can be
passed around without regard to which column/result set it came from.
Indeed the DB_NUMERIC and CS_NUMERIC types can be created on the client
side. So, I saw two ways of handling this. 

1) malloc the *_NUMERIC structure when asked for the column (as in
dbdata() function). The problems with this approach is we need to track
the allocations and decide when its safe to clean them up, which presumbly
means during dbnextrow() which would generally slow things down since we
would then be malloc/free'ing for each row (10,000 rows and it could get
quite serious).

2) store the *_NUMERIC structure (DB_NUMERIC and CS_NUMERIC are 
indentical, so dblib and ctlib can refer to the same value) directly in
the row buffer. The problem here is that a numeric of precision 10, for
instance, is 6 bytes on the wire but the *_NUMERIC structures are 35
bytes, so there is some overhead in memory (35*number of numerics*rows in
row buffer). The second problem is what to do about call level interfaces
whose numerics dont look like dblib/ctlib (ODBC comes to mind). But, on
the other hand it's easier to implement for dblib/ctlib.

So, I got sqsh 1.4 working with numerics in a very basic way (no scaling,
just simple numeric to string conversion) using the second way, but I'm
not really satisfied that this is the best way (although given the
constraint of implementing someone elses APIs there may not be an ideal
way to do it). I was hoping someone might have a better idea though.


Brian