Thread: Re: FW: OID, compatible=7.1 and getBinaryStream() in 7.4driver
I have applied the patch against my CVS sources, built a jar and tested it. Everything now seems to work fine. Once thepatch is in CVS I will check it out and rebuild the driver to be used in our development environment. -----Original Message----- From: Kris Jurka [mailto:books@ejurka.com] Sent: Wednesday, December 17, 2003 4:46 PM To: Alexey Yudichev Cc: pgsql-jdbc@postgresql.org Subject: Re: FW: [JDBC] OID, compatible=7.1 and getBinaryStream() in 7.4driver On Wed, 17 Dec 2003, Kris Jurka wrote: > > > On Wed, 17 Dec 2003, Alexey Yudichev wrote: > > > [I can't use 7.1 style large objects with a 7.4 database.] > > Here's a patch to fix this. The core problem was a check to determine > if it should use the version 2 or 3 protocol was checking the > server version instead of the compatibility version. While > locating this I found two other bugs. The query to retrieve the > oids for the large object functions had an incorrect WHERE clause > when trying to deal with schemas. Also the V3 fastpath API didn't > handle multiargument functions properly. > Actually the last part about multiargument functions was correct to begin with. Here's the patch with only the first two changes. Kris Jurka
patched and backpatched, thanks guys! Dave On Wed, 2003-12-17 at 10:03, Alexey Yudichev wrote: > I have applied the patch against my CVS sources, built a jar and tested it. Everything now seems to work fine. Once thepatch is in CVS I will check it out and rebuild the driver to be used in our development environment. > > -----Original Message----- > From: Kris Jurka [mailto:books@ejurka.com] > Sent: Wednesday, December 17, 2003 4:46 PM > To: Alexey Yudichev > Cc: pgsql-jdbc@postgresql.org > Subject: Re: FW: [JDBC] OID, compatible=7.1 and getBinaryStream() in 7.4driver > > > > > On Wed, 17 Dec 2003, Kris Jurka wrote: > > > > > > > On Wed, 17 Dec 2003, Alexey Yudichev wrote: > > > > > [I can't use 7.1 style large objects with a 7.4 database.] > > > > Here's a patch to fix this. The core problem was a check to determine > > if it should use the version 2 or 3 protocol was checking the > > server version instead of the compatibility version. While > > locating this I found two other bugs. The query to retrieve the > > oids for the large object functions had an incorrect WHERE clause > > when trying to deal with schemas. Also the V3 fastpath API didn't > > handle multiargument functions properly. > > > > Actually the last part about multiargument functions was correct to begin > with. Here's the patch with only the first two changes. > > Kris Jurka > > > ---------------------------(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 > >
On 17 Dec 2003, Dave Cramer wrote: > patched and backpatched, The test case you've added has some issues: 1) It has a fixed connection string instead of using the connection parameters from TestUtil. 2) It prints output to standard out instead of using asserts 3) It has the original comments describing the bug which are confusing if you expect the test to pass. 4) It uses windows end of line characters. This patch fixes these issues. Additionally doing some testing revealed another bug with compatibilty version handling. If the user does not explicitly specify a "compatible" parameter it defaults to the jdbc driver version. It should instead default to the server version the connection is for because a newer driver can talk to older databases. I've attached a patch for this as well. Kris Jurka
Attachment
On Wed, Dec 17, 2003 at 07:17:43PM -0500, Kris Jurka wrote: > Additionally doing some testing revealed another bug with compatibilty > version handling. If the user does not explicitly specify a "compatible" > parameter it defaults to the jdbc driver version. It should instead > default to the server version the connection is for because a newer driver > can talk to older databases. Is this correct? I thought compatible=X meant "behave like the driver in version X behaved" i.e. it was there for handling incompatible driver changes, not server-side changes. -O
On Thu, 18 Dec 2003, Oliver Jowett wrote: > On Wed, Dec 17, 2003 at 07:17:43PM -0500, Kris Jurka wrote: > > > Additionally doing some testing revealed another bug with compatibilty > > version handling. If the user does not explicitly specify a "compatible" > > parameter it defaults to the jdbc driver version. It should instead > > default to the server version the connection is for because a newer driver > > can talk to older databases. > > Is this correct? I thought compatible=X meant "behave like the driver in > version X behaved" i.e. it was there for handling incompatible driver > changes, not server-side changes. > Right, the actual problem was that some of the checks to determine whether to use the V2 or V3 protocol were using the compatible version number instead of the protocol version of the established connection. This patch fixes the real problem instead of mucking with the really unrelated compatible parameter. Kris Jurka
Attachment
Oliver, Your understanding is correct. Compatible version controls changes in functionality between releases of the jdbc client code and has nothing to do with the server version. So in cases like blob support where the functionality of the driver changed in a non-backwardly compatible way between versions 7.1 and 7.2 of the driver the compatible parameter allows you to change back to the old way of doing things. This allows you to use the newest version of the driver to take advantage of the new functionality and bug fixes and gives you a window of time to upgrade your code to convert over to the new way of doing things. It doesn't matter what the server version is in these cases. thanks, --Barry Oliver Jowett wrote: > On Wed, Dec 17, 2003 at 07:17:43PM -0500, Kris Jurka wrote: > > >>Additionally doing some testing revealed another bug with compatibilty >>version handling. If the user does not explicitly specify a "compatible" >>parameter it defaults to the jdbc driver version. It should instead >>default to the server version the connection is for because a newer driver >>can talk to older databases. > > > Is this correct? I thought compatible=X meant "behave like the driver in > version X behaved" i.e. it was there for handling incompatible driver > changes, not server-side changes. > > -O > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings >