Re: BEGIN inside transaction should be an error

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: BEGIN inside transaction should be an error
Дата
Msg-id 20060510212608.GC14476@svana.org
обсуждение исходный текст
Ответ на Re: BEGIN inside transaction should be an error  ("Jim C. Nasby" <jnasby@pervasive.com>)
Ответы Re: BEGIN inside transaction should be an error  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: BEGIN inside transaction should be an error  ("Marko Kreen" <markokr@gmail.com>)
Список pgsql-hackers
On Wed, May 10, 2006 at 04:03:51PM -0500, Jim C. Nasby wrote:
> On Wed, May 10, 2006 at 12:31:52PM +0200, Mario Weilguni wrote:
> > Maybe. I just want to emphasize that it will break existing applications.
>
> If the existing application is trying to start a new transaction from
> within an existing one, I'd say it's already broken and we're just
> hiding that fact.

Well maybe, except the extra BEGIN is harmless. I'm thinking of the
situation where a connection library sends a BEGIN on startup because
it wants to emulate a non-autocommit mode. The application then
proceeds to handle transactions itself, sending another BEGIN and going
from there.

We'll have just broken this perfectly working application because it
failed the purity test. The backward compatability issues are huge and
it doesn't actually bring any benefits.

How do other database deal with this? Either they nest BEGIN/COMMIT or
they probably throw an error without aborting the transaction, which is
pretty much what we do. Is there a database that actually aborts a
whole transaction just for an extraneous begin?

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [TODO] Allow commenting of variables ...
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: sblock state on FreeBSD 6.1