FreeTDS Development Group

["James Harper" <james.harper AT bendigoit.com.au>]

> Hi James,
> 
> You've done a bunch of work, and I'd like to see it included in the
main
> distribution.  The server code has a few possible uses, not least of
which
> is to create a TDS front end to other databases.  Or, as perhaps you
are
> doing, non-databases.  The population of interested parties may be
small,
> but you're certainly not alone.
> 
> It would be great, if you're up for it, to preserve the 4.2 capability
and
> add 7.0 (and/or 8.0) to the mix.  The reason to keep 4.2 is that it's
more
> similar to 5.0, which is what Sybase uses.  Moving to 7.0-only would
> exclude the use of Sybase clients, whereas a 4.2 server (as you found)
is
> accessible by both vendors' clients.
> 
> If you would provide a patch that adds 7.0 capability, I would be very
> pleased to apply and acknowledge it.

That's enough incentive then. I was planning on putting it in a patch if
anyone was interested.

What I'm actually trying to do is provide a tds proxy to a postgresql
backend, but if there is even a hint of interest in another backend (eg
mysql) then I'll try and make it a bit flexible...

It works currently but only for char and varchar types, and only if you
submit postgresql queries. Once I have the queries working properly I
plan to write a parser to convert PostgreSQL queries to T-SQL on the
fly.

Ultimately I'd like to take an application that is written for Microsoft
SQL Server and make it run against PostgreSQL without any modification.
A few hurdles to overcome before that though.

What I've found so far is that the code in src/server/ is horribly out
of date and (at least for what I wanted to do) broken. Not too hard to
fix though, and maybe only broken because of other changes to the client
code.

How would the freetds community feel if I submitted patches that changed
the client side to better accommodate the server side? One thing I found
is that the code in src/server tries to use a resinfo structure to
extract the column info out of, and to send row data, but with one char
* field containing all the row data it seems like a huge waste to
assemble your row data into that format (taking into account offsets
etc), just so that tds_send_row can disassemble it again to put it into
the wire. Much better for the server code to have a per column data
pointer.

Another thing is there are a bunch of functions associated with finding
out if a field is fixed, nullable, etc. These would need to be a bit
more precise to be properly useful for server code.

I'll try and send a patch through shortly, or at least within a week.

Thanks

James