Re: New problem with SET/autocommit - Mailing list pgsql-hackers

From Tom Lane
Subject Re: New problem with SET/autocommit
Date
Msg-id 10186.1035091608@sss.pgh.pa.us
Whole thread Raw
In response to New problem with SET/autocommit  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: New problem with SET/autocommit  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom, you mentioned suppressing the WARNING on COMMIT of an empty
> transaction would make it hard to know when you are in a transaction,
> but I was suggesting suppressing the warning only when autocommit was
> off, so by definition you are always in a transaction, sort of.  You are
> in a transaction, but perhaps an empty one.

I don't understand why you're labeling this behavior as a problem.
To me, it's the expected behavior, it's useful in debugging, and it
does not actually break anything.  (A WARNING is not an ERROR.  Though
I'd not object if you'd like to downgrade the begin/commit/rollback
wrong-state WARNINGs to NOTICEs, like they were before.)

> Should it be OK to issue a
> COMMIT of an empty transaction when autocommit is off?

We need to be careful about adding more and more special cases to
the transactional rules.  The more there are, the more confusing
and hard-to-maintain the system will be.  I don't think this proposed
special case is justified: it has no value except to suppress a notice.
Moreover, it's suppressing a notice in a context where the user
demonstrably has a misunderstanding of the transactional behavior.
Don't we usually throw notices to try to teach people what they
may be doing wrong?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: DBD::PG - any works to be compatile with 7.3 ?
Next
From: Peter Mount
Date:
Subject: Re: /contrib/retep to gborg