Обсуждение: 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

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

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
>