Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> I don't think it *can* be fixed in a reasonable fashion until we have
>> notification to the client side about what the backend's transaction
>> state is; which is one of the protocol-change items for 7.4.
> Why can't we just turn on auto-commit when we start the session:
> SET autocommit = true;
How's that help? If the user turns it off again, we still break.
More to the point, we can hardly claim any level of SQL compliance if
either libpq or psql try to prevent you from using the autocommit-off
mode ... but both contain problematic code (mostly in the startup and
large-object-support areas).
The real problem here is that the client code cannot know how to behave
(ie, whether to issue BEGIN and/or COMMIT) unless it knows the current
autocommit setting and current transaction state. And getting that info
in any reliable fashion requires a protocol change, AFAICS.
There are some things we can tweak to make the clients less broken than
they are now --- for instance, all of libpq's startup-time SET commands
could be switched to "BEGIN; SET ...; COMMIT;" which will work the same
with or without autocommit --- but I don't think we can expect to fix
large-object support, for example, without the protocol change.
>> Oh, didn't you put in that patch to provide a GUC level control?
> Yes, but what level do you set it at to turn it off?
FATAL? PANIC?
regards, tom lane
