Re: New problem with SET/autocommit

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: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New problem with SET/autocommit
Date: 2002-10-20 05:26:48
Message-ID: 10186.1035091608@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Mount 2002-10-20 10:12:07 Re: /contrib/retep to gborg
Previous Message Bruce Momjian 2002-10-20 04:41:08 Re: DBD::PG - any works to be compatile with 7.3 ?