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) ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match