Thread: New problem with SET/autocommit
> Remember how we make SET/SHOW/RESET _not_ be part of a multi-statement > transaction when it is at the start of a transaction and autocommit is > off? > > Well, look at this: > > test=> SET random_page_cost = 2; > SET > test=> COMMIT; > WARNING: COMMIT: no transaction in progress > COMMIT > > The WARNING happens with SHOW and RESET too. I wonder if we should > suppress the WARNING of a COMMIT with no statements when autocommit is > off. This will probably be better for portability, though again, it is > confusing. [ Sorry, I deleted Tom's reply.] 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. Should it be OK to issue a COMMIT of an empty transaction when autocommit is off? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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
OK, I guess it isn't a problem. --------------------------------------------------------------------------- Tom Lane wrote: > 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073