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: | Curt Sampson <cjs(at)cynic(dot)net>, snpe <snpe(at)snpe(dot)co(dot)yu>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [JDBC] problem with new autocommit config parameter and jdbc |
Date: | 2002-09-10 19:55:57 |
Message-ID: | 21616.1031687757@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:
> That seems messy. What you are saying is that if autocommit is off,
> then in:
> SET x=1;
> UPDATE ...
> SET y=2;
> ROLLBACK;
> that the x=1 doesn't get rolled back bu the y=2 does?
Yes, if you weren't in a transaction at the start.
> I can't see any good logic for that.
How about "the SQL spec requires it"? Date seems to think it does,
at least for some variables (of course we have lots of variables
that are not in the spec).
I can't find anything very clear in the SQL92 or SQL99 documents,
and I'm not at home at the moment to look at my copy of Date, but
if Curt's reading is correct then we have spec precedent for acting
this way.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-09-10 20:00:26 | Re: [JDBC] problem with new autocommit config parameter and |
Previous Message | scott.marlowe | 2002-09-10 19:50:44 | Re: problem with new autocommit config parameter and jdbc |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-09-10 20:00:26 | Re: [JDBC] problem with new autocommit config parameter and |
Previous Message | scott.marlowe | 2002-09-10 19:50:44 | Re: problem with new autocommit config parameter and jdbc |