From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Barry Lind <barry(at)xythos(dot)com>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: problem with new autocommit config parameter and jdbc |
Date: | 2002-09-09 18:53:56 |
Message-ID: | 12677.1031597636@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Barry Lind wrote:
>> How should client interfaces handle this new autocommit feature? Is it
>> best to just issue a set at the beginning of the connection to ensure
>> that it is always on?
> Yes, I thought that was the best fix for apps that can't deal with
> autocommit being off.
If autocommit=off really seriously breaks JDBC then I don't think a
simple SET command at the start of a session is going to do that much
to improve robustness. What if the user issues another SET to turn it
on?
I'd suggest just documenting that it is broken and you can't use it,
until such time as you can get it fixed. Band-aids that only partially
cover the problem don't seem worth the effort to me.
In general I think that autocommit=off is probably going to be very
poorly supported in the 7.3 release. We can document it as being
"work in progress, use at your own risk".
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daryl Beattie | 2002-09-09 19:01:23 | Re: [JDBC] problem with new autocommit config parameter |
Previous Message | Peter Eisentraut | 2002-09-09 18:41:41 | Re: Proposal: Solving the "Return proper effected tuple |
From | Date | Subject | |
---|---|---|---|
Next Message | Daryl Beattie | 2002-09-09 19:01:23 | Re: [JDBC] problem with new autocommit config parameter |
Previous Message | Felipe Schnack | 2002-09-09 18:18:54 | Re: postgresql-java |