Thread: 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, Pennsylvania19026
> -----Original Message----- > From: Bruce Momjian > Sent: Sunday, February 11, 2001 11:01 AM > To: PostgreSQL-development > Subject: [HACKERS] 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. 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 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. > > 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, Pennsylvania19026
"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