I can tackle 1 and 2. They will also serve as a good introduction to both
ODBC, the driver and unicode.
Where can I get details/specs for all these?
Also another thing that I have come across when using psqlODBC with OTL
(http://otl.sourceforge.net/home.htm) is that the driver
will not work when inserting data with a buffer size other than 1 (this is
the size of the otl_stream buffer).
[mailto:pgsql-odbc-owner(at)postgresql(dot)org]On Behalf Of Dave Page
Sent: Wednesday, June 30, 2004 12:45 PM
Subject: [ODBC] ODBC Developers
As many of you will know, I recently placed a news item on
www.postgresql.org to try to get some new developers working on
psqlODBC. I was pleseantly surprised to find that after just a few days
I had received eight responses from people interested in joining the
project. This message has been BCC'd to them.
First of all, I'd like to say thank you to those that responded - input
from all of you would be most welcome as there are a number of end users
keen to see psqlODBC move forwards. If you have not done so already,
please subscribe to the psql-odbc(at)postgresql(dot)org mailing lists (just
send a message containing the word 'subscribe' (wiithout the quotes) to
In the remainder of this message, I'll try to outline some history and
what I see as the future for the driver. This is all open for discussion
on-list so feel free to chip in with comments.
I first started using psqlODBC back around 1997, when it was maintained
by solely Byron Nikolaidis from Insight Distribution Systems. When Byron
stopped working on the driver, after a period with no maintainer,
Hiroshi Inoue took over, and I started looking after the website and
managing the releases of the driver. It should be noted that whilst I
have done some work on the internals, I am by no means an expert on how
the driver works. After some years, Hiroshi was also forced to quit
working on the driver, thus leaving it in it's current state. At the
same time, my time has also been refocussed elsewhere as I rarely use
the driver nowadays (some of you will know that my primary project,
pgAdmin, now uses libpq), thus I only really have time to chip in now
The upshot is, that we have a community of users, and a project that
needs to move forwards, but currently isn't.
Over the last few releases, we have been introducing new versions of the
driver, one with ODBC 3 compliance, and one with ODBC 3 compliance, and
Unicode support. We have gradually been promoting the driver to make the
ODBC 3 Unicode driver the default. Changes to CVS have already been
committed to make this the only version of the driver shipped in future
releases, though this has not been tested under *nix at present.
There are a number of tasks that need addressing - following any
discussion, I'd be happy if any of our new volunteers could co-ordinate
efforts to undertake this work. This list is not necessarily complete -
corrections/comments welcome :-)
1) ODBC 3 compliance should be checked. Are all the required ODBC
functions present. Do they work as expected.
2) Ditto, Unicode versions of all the functions.
3) An audit of the code for possible buffer overrun problems should be
4) An update to the v3 fe-be protocol is required.
5) SSL support should be added.
6) The GUI needs a cleanup (move to use of tabs rather than separate
dialogues, and a 'test connection' button?).
7) Documentation and the website needs updating (as always :-) )
(note; would 4 & 5 be better solved by replacing the current code with
In addition, there are always bugs with new versions, and the latest
snapshot is no exception. These need to be fixed as reported.
Initially, any work that is undertaken should be supplied to the list as
patches for review following any appropriate discussion. If the general
concencus is that a patch is good, then I will apply it to CVS. I will
also continue to produce releases for now. In the future, we can look at
giving more people CVS commit privileges once they have proven the
quality of their work (as is the norm for any good open source project).
So, I'll finish up now. I hope I haven't put off any one and welcome any
comments (or a flurry of patches :-) ).
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
In response to
pgsql-hackers by date
|Next:||From: Christopher Kings-Lynne||Date: 2004-07-01 07:11:27|
|Subject: Re: Adding column comment to information_schema.columns|
|Previous:||From: Alvaro Herrera||Date: 2004-07-01 06:11:24|
|Subject: Re: Performance with new nested-xacts code|
pgsql-odbc by date
|Next:||From: Dave Page||Date: 2004-07-01 07:22:05|
|Subject: Re: ODBC Developers|
|Previous:||From: Peter Eisentraut||Date: 2004-06-30 17:11:14|
|Subject: Re: ODBC Developers|