From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Nested xacts: looking for testers and review |
Date: | 2004-05-28 20:14:44 |
Message-ID: | 20040528201444.GB3272@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 28, 2004 at 04:05:40PM -0400, Bruce Momjian wrote:
Hm, you are right that there needs to be a more automatic way of doing
this.
> One interesting idea would be for COMMIT to affect the outer
> transaction, and END not affect the outer transaction. Of course that
> kills the logic that COMMIT and END are the same, but it is an
> interesting idea, and doesn't affect backward compatibility because
> END/COMMIT behave the same in non-nested transactions.
How about "COMMIT SUB" and "END SUB"? I don't feel it's good to give
different meaning to COMMIT versus END, but this is only a gut kind of
thing and I could be convinced otherwise. It is even easier to
differentiate COMMIT/END than adding a parameter to them.
I mean, COMMIT SUB would not affect the state of the outer transaction,
while COMMIT would.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"In fact, the basic problem with Perl 5's subroutines is that they're not
crufty enough, so the cruft leaks out into user-defined code instead, by
the Conservation of Cruft Principle." (Larry Wall, Apocalypse 6)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-05-28 20:45:28 | Re: SELECT * FROM <table> LIMIT 1; is really slow |
Previous Message | Bruce Momjian | 2004-05-28 20:05:40 | Re: Nested xacts: looking for testers and review |