>Also, any thoughts on making the LO vs. bytea behaviour a separate
>option, rather than lumping it in with 7.1 compatibility? It seems quite
>possible that you might want to use LOs for get/setBytes() but use the
>most up to date driver behaviour elsewhere.
Are there any other changes in driver behaviour triggered by compatibility=7.1 other than LO-related ones? If yes, that
wouldbe a good idea to separate them from LO changes, because LOs are the only reason I use compatibility=7.1
parameter.
-----Original Message-----
From: Oliver Jowett [mailto:oliver@opencloud.com]
Sent: Monday, October 25, 2004 12:16 PM
To: Kris Jurka
Cc: pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] Problems with protocol V3 after migration to latest driver
Kris Jurka wrote:
> The first time through it does not fail because the driver
> needs to query the backend to get some setup information for large objects
> which starts a transaction.
Sounds like that is (another) bug .. it should be using the
QUERY_SUPPRESS_BEGIN flag for driver-generated queries to avoid starting
a transaction accidentally. I fixed that in various other places but
didn't think to check the LO code.
Also, any thoughts on making the LO vs. bytea behaviour a separate
option, rather than lumping it in with 7.1 compatibility? It seems quite
possible that you might want to use LOs for get/setBytes() but use the
most up to date driver behaviour elsewhere.
-O
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly