| 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: | Whole Thread | Raw Message | 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 |