Re: Two features left

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jon Swinth <jswinth(at)atomicpc(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Jean-Luc Lachance <jllachan(at)nsd(dot)ca>, pgsql-general(at)postgresql(dot)org
Subject: Re: Two features left
Date: 2002-11-27 22:31:18
Message-ID: 28523.1038436278@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Jon Swinth <jswinth(at)atomicpc(dot)com> writes:
> Ok, so it looks like your nested transactions and savepoints are really the
> same thing. The question is, are you going to change the way SQL exceptions
> are handled so that simply abort that SQL statement don't require a rollback?
> With your enhancement, it sounds like calling BEGIN before each SQL statement
> could acheive what I am asking for, but the issue is existing applications
> will not expect to have to do so.

Au contraire: existing PG applications would be broken completely if the
behavior of error rollback suddenly changes.

There is also an efficiency issue: nested transactions will not be free,
and one should not be forced to pay for them when not needed.

It might be reasonable to have a GUC parameter that enables an implicit
subtransaction around each command in a transaction block (perhaps only
at the topmost nesting level?) --- but it won't become the default
behavior in the foreseeable future.

Note also that Bruce has no expectation of supporting subtransactions
within a function call; that opens a much larger can of worms than what
he's already getting into. So this facility would only be available at
the interactive-command level.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Zengfa Gao 2002-11-27 22:45:43 Shared library
Previous Message Neil Conway 2002-11-27 22:11:11 Re: Sequence (related) Problem