ODBC backward versions
I checked the logs, and we released the new 6.4 backend protocol on
1998-10-30. That was 2.5 years ago.
We normally allow older clients to communicate with newer servers, but
often we don't support newer clients talking to older servers, sometimes
even servers one release in the past. The reason is that the backend
communication code gets confusing. For example, I know there were some
libpq releases that could not talk to servers from the previous release.
We did allow newer servers to talk to older clients because it is harder
to upgrade many clients than a single server.
Seems the <=6.3 compatibility code in our current ODBC is just adding
confusion for coders and users and should be removed. Tom Lane agreed.
If someone thinks it should be kept, please speak up.
Thanks.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-----Original Message-----
From: Bruce Momjian
Sent: Sunday, February 11, 2001 11:01 AM
To: PostgreSQL-development
Subject: [HACKERS] ODBC backward versionsI checked the logs, and we released the new 6.4 backend protocol on
1998-10-30. That was 2.5 years ago.We normally allow older clients to communicate with newer servers, but
often we don't support newer clients talking to older servers, sometimes
even servers one release in the past. The reason is that the backend
communication code gets confusing. For example, I know there were some
libpq releases that could not talk to servers from the previous release.
Libpq 2.x couldn't talk to pre-6.4 servers. Fortunately ODBC has never
used libpq and could talk to wide range of versions. Should ODBC
throw away the luck ?
We did allow newer servers to talk to older clients because it is harder
to upgrade many clients than a single server.Seems the <=6.3 compatibility code in our current ODBC is just adding
confusion for coders and users and should be removed. Tom Lane agreed.
Where's real coders for psqlodbc driver in the first place ?
Byron has been unavailable for a long time and I've seen
few improvements for a year or so. Does removing pre-6.4
code improve the status ? The problem is that there has
been no maintainer of odbc driver.
Regards,
Hiroshi Inoue
-----Original Message-----
From: Bruce Momjian
Sent: Sunday, February 11, 2001 11:01 AM
To: PostgreSQL-development
Subject: [HACKERS] ODBC backward versionsI checked the logs, and we released the new 6.4 backend protocol on
1998-10-30. That was 2.5 years ago.We normally allow older clients to communicate with newer servers, but
often we don't support newer clients talking to older servers, sometimes
even servers one release in the past. The reason is that the backend
communication code gets confusing. For example, I know there were some
libpq releases that could not talk to servers from the previous release.Libpq 2.x couldn't talk to pre-6.4 servers. Fortunately ODBC has never
used libpq and could talk to wide range of versions. Should ODBC
throw away the luck ?
Well, the ability to give users choices of old servers is confusing
them. 6.4 is so old, they assume they need a newer one to talk to 7.1,
and hopefully clearer code will help coders in the future.
We did allow newer servers to talk to older clients because it is harder
to upgrade many clients than a single server.Seems the <=6.3 compatibility code in our current ODBC is just adding
confusion for coders and users and should be removed. Tom Lane agreed.Where's real coders for psqlodbc driver in the first place ?
Byron has been unavailable for a long time and I've seen
few improvements for a year or so. Does removing pre-6.4
code improve the status ? The problem is that there has
been no maintainer of odbc driver.
We have some new people interested, like Julie Case and I think a few
others. I just reformatted the entire odbc directory, which will
hopefully make it clearer and attract patches. I know it is clearer for
me now.
So, no, removing 6.4 does not improve ODBC, but it makes it simpler, and
I doubt anyone wants to talk to a 6.3 server using 7.1 ODBC.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
Does removing pre-6.4 code improve the status ?
Yes, it does (IMHO anyway) because it removes a configuration option
that is confusing new users. The odds that someone will want to use 7.1
ODBC with a pre-6.4 server seem very small to me, while we do frequently
see questions about the 6.2/6.3/6.4 protocol switch.
The problem is that there has been no maintainer of odbc driver.
That's certainly true. I hope that someone will start taking
responsibility for this code again.
regards, tom lane
Tom Lane wrote:
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
Does removing pre-6.4 code improve the status ?
Yes, it does (IMHO anyway) because it removes a configuration option
that is confusing new users.
Right. There's even an idea(not mine) to remove
the option by automatically detecting the server's
version. However the option isn't entirely wrong
because users could recognize by the option that
ODBC driver supports multiple server versions.
Unfotunately people are easy to forget that ODBC
driver supports multiple versions even though the
option exists.
The odds that someone will want to use 7.1
ODBC with a pre-6.4 server seem very small to me, while we do frequently
see questions about the 6.2/6.3/6.4 protocol switch.The problem is that there has been no maintainer of odbc driver.
That's certainly true. I hope that someone will start taking
responsibility for this code again.
I myself have been using ODBC driver in production
system. The absense of a maintainer has been a
problem for me. Unfortunately I'm not familiar
with ODBC that well and couldn't be a maintainer.
I know a person who could maintain our ODBC driver
other than Byron. I always recommended him to be a
maintainer but he hasn't agreed. Recently I've
fixed some light bugs unwillingly but it's hard
for me to fix complicated bugs. For exmaple it's
very hard for me to check if Ludek Finstrlein's
patch([ODBC] pgsqODBC binding parameters II) is
right. I'm expecting for the person to answer the
question.
Regards,
Hiroshi Inoue