FreeTDS Development Group

[James K. Lowden <jklowden AT speakeasy.org>]

All, 

How has the experience been with Bill's new conversion stuff?  Are we
happy?  

I'm a little not, on principle.  But if the new code works, I say it's
high time we kicked it out the door.  

Bill, I'm just not fond of libraries allocating memory and expecting me to
free it.  I would actually prefer, as you said you don't, that tds_convert
use an output buffer provided by the API, and let the API "clear up the
mess afterwards".   

I can think of only two reasons for tds_convert to allocate memory:

1.      The caller doesn't know how big the output buffer should be.
2.      tds_convert wants to give the caller some choice about what to do with
the output buffer in the event it's not big enough.  

I think case #1 never happens and case #2 is unimportant.  

Other opinions?  Would anyone greatly mind if I slightly rewound Bill's
logic?  It can wait for 0.61.  

But that's a niggle.  The really really great news AIUI is that we have a
complete working datatype conversion matrix.  Do I in fact understand
correctly?  (Curiously, it's not in the ChangeLog.)

Frediano, you have several open patches posted.  It looks like some of
them are OBE (overcome by events, no longer needed).  Could you take a
look and tell me what's still needed, please?  

Brian, I had insight into my iconv problem: On my OSF1 box, libsybdb had
unresolved references to the iconv functions.  I think that's because ar
(?) didn't look in the right place when the library was built, because of
some assumption in the configure script about directories to include.  I'm
going to look into this further.  

I will also fix up tds_willconvert, if only to facilitate testing Bill's
conversion matrix.  I already have a utility that attempts to convert
every column in a result set to every available datatype.  I can post it
if anyone else cares.