Re: FW: OID, compatible=7.1 and getBinaryStream() in 7.4driver

See attached.

-----Original Message-----
From: Dave Cramer [mailto:pg(at)fastcrypt(dot)com]
Sent: Tuesday, December 16, 2003 4:35 PM
To: Alexey Yudichev
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: FW: [JDBC] OID, compatible=7.1 and getBinaryStream() in 7.4driver + 7.4 database

Alexey,

Can you put together a test case and I'll try to fix it?

Dave
On Tue, 2003-12-16 at 04:40, Alexey Yudichev wrote:
> Can I have any comments on this?
>
> -----Original Message-----
> From: Alexey Yudichev
> Sent: Wednesday, December 10, 2003 12:17 PM
> To: pgsql-jdbc(at)postgresql(dot)org
> Subject: [JDBC] OID, compatible=7.1 and getBinaryStream() in 7.4 driver
> + 7.4 database
>
>
> I have noticed that I can use only latest 7.4 driver with 7.4 database. I tried both driver from jdbc.postgresql.org (7.4 beta3) and from CVS (:pserver:anoncvs(at)anoncvs(dot)postgresql(dot)org:/projects/cvsroot) and discovered that with compatible=7.1 flag invoking rs.getBinaryStream() or rs.getBytes() on an OID column blocks forever (somewhere in java.net.SocketInputStream so I guess it's a server that is not responding). According to 7.4 documentation http://www.postgresql.org/docs/current/static/jdbc-binary-data.html, this should work. getBLOB() works great, but JBoss 3.2 server which I am using is only capable of dealing with large objects via getBinaryStream()/setBinaryStream().
>
> Combination "OID, compatible=7.1 and getBinaryStream()" worked well in PostgreSQL 7.2 with latest 7.3 driver.
>
> What options do I have? I could migrate to bytea although I don't liked the performance of it. But before I do that I want to make sure that this issue is a bug that is about to be fixed or something different.
> Thanks.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>
>

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.

Kris Jurka

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