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
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 |