Alvaro Herrera wrote: > > 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. > > I implemented this behavior by using parameters to COMMIT/END. I didn't > want to add new keywords to the grammar so I just picked up > "COMMIT WITHOUT ABORT". (Originally I had thought "COMMIT IGNORE > ERRORS" but those would be two new keywords and I don't want to mess > around with the grammar. If there are different opinions, tweaking the > grammar is easy). > > So the behavior I originally implemented is still there: > > alvherre=# begin; > BEGIN > alvherre=# begin; > BEGIN > alvherre=# select foo; > ERROR: no existe la columna "foo" > alvherre=# commit; > COMMIT > alvherre=# select 1; > ERROR: transacci?n abortada, las consultas ser?n ignoradas hasta el fin de bloque > de transacci?n > alvherre=# commit; > COMMIT
Perfect. Your suggested behavior is best. I think I like "COMMIT IGNORE ABORT" best, but we can disucss this some more. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
