Re: New problem with SET/autocommit

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: New problem with SET/autocommit
Дата
Msg-id 10186.1035091608@sss.pgh.pa.us
обсуждение исходный текст
Ответ на New problem with SET/autocommit  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: New problem with SET/autocommit  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: DBD::PG - any works to be compatile with 7.3 ?
Следующее
От: Peter Mount
Дата:
Сообщение: Re: /contrib/retep to gborg