[freetds] New release roadmap
James K. Lowden
jklowden at freetds.org
Wed Mar 11 21:01:25 EDT 2009
Frediano Ziglio wrote:
> 2009/3/10 James K. Lowden <jklowden at freetds.org>:
> > I wasn't thinking about a new release. Any particular reason you want
> > one soon? I think there's work to do.
> Mainly I can see
> - bcp improvement
> - odbc parameters
> - odbc wide character support
> - better odbc error report
> - odbc tests updates (style and improvements)
> not that much but importants
OK, agreed. Let's decide what we need to do.
> > 1. Separating connect and login.
> > "Server SYBASE not found" must die.
> Another problem is name resolution. Personally I don't like host name
> resolution in config.c... I would prefer in net.c and during
> connection, not during configuration reading (it seems more correct).
Yeah. I don't think that matters too much for this release, but it would
be nice to clean up one day.
We're moving in the direction of not needing freetds.conf in simple cases,
which would be great. No matter what, though, I don't see any point
anymore in falling back to a hard-coded "SYBASE" name. It just confuses
most people when they're setting up their configuration.
> > 2. TDSVER = auto. I want this to be the default.
> ok, are you satisfied with current implementation??
Not completely. I don't remember exactly where I left off, but I think
there's some interaction with the connect/login separation I'm working on.
> Perhaps one
> could object that if somebody wants fast connection could set
> parameters fixed (specify port and protocol)....
Exactly. I would say exactly that.
> > 3. A better form of tsql -L.
> > 4. Modifying instance-name lookup to use bind/listen instead of 16
> > attempts.
> I replicate mssql client way...
I still think bind/listen is better (and quicker).
> > 5. Making db-lib unit tests portable and testing them on all three
> > platforms. We should do the same with the others, too.
> What do you mean by "portable" ?? Three platforms ?? Linux, Windows and
Sorry, no. Sybase, Microsoft, and FreeTDS. I want to make it easy to run
the tests with different versions and compare results.
> > I've made no progress on:
> > 1. Fixing BCP to make file-encoding a property of the file, not of
> > the connection environment. (LANG might not agree with a file's
> > encoding.)
> I was not aware of this problem...
Sure you are! You know there's no way to tell bcp what the file's
> > 2. The most important db-lib bug, reported a few months ago. Under
> > certain circumstances, it apparently ignores resultsets. I haven't
> > got a good unit test for it, and I don't know if the vendor
> > implementations behave the same or differently.
> ?? I don't remember ?? We got a report from ML I imagine...
Date: Tue, 11 Nov 2008 12:02:14 GMT
From: "Hayes, Ted (London)" <rogercarlton_hayes at ml.com>
Subject: [freetds] seems dblib can get TDS protocol wrong in unusual case
That is why we need portable db-lib unit tests.
> > 3. Reducing memory requirements for TEXT/IMAGE columns when querying.
> limiting text store into rows?? I think this could be posted to a
> future release. Personally I don't like the way BLOB are handled.
> Looking at the code you can find a lot of rows that test for BLOBs
> (is_blob_type) and read TDSBLOB->textvalue from column_data. I think
> it would be more readable to see only column_data...
We support dbreadtext() and dbmoretext(), but we don't use them in e.g.
freebcp. For writing, we don't support bcp_moretext. We could (but don't)
get around that in freebcp, and of course applications don't have that
Yes, it can wait for a future release, but it's the most important
So, open issues for me:
1. connect/login cleanup (& defaults & bind/listen) .
2. db-lib resultset bug.
3. bcp encoding.
4. bcp_moretext (can wait).
5. documentation updates for above.
More information about the FreeTDS