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 pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073