From: | Kris Jurka <books(at)ejurka(dot)com> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Problems with protocol V3 after migration to latest driver |
Date: | 2004-10-25 21:06:53 |
Message-ID: | Pine.BSO.4.56.0410251601030.26148@leary.csoft.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On Mon, 25 Oct 2004, Oliver Jowett wrote:
> 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.
This might be a little tricky as the large object code uses just the
public java.sql.* api. This situation is somewhat analogous to the
DatabaseMetaData calls that we decided should start transactions. In any
case I'm not sure it really matters. The only time the largeobject api
is initialized when a query won't immediately follow is if they are using
the LargeObjectManeger directly and not through the compatible=7.1 or
getBlob.
> 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.
Seems like a good idea.
Kris Jurka
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2004-10-25 22:50:55 | Re: Problems with protocol V3 after migration to latest driver |
Previous Message | Kris Jurka | 2004-10-25 21:00:51 | Re: Problems with protocol V3 after migration to latest driver |