Today, in a message to Greg Speegle, Peter Mount wrote:
>
> I'm not sure if the term's "aborted" (been a horrible week, etc), but
> as the drop failed, any transaction its contained within must also
> fail - thats the point of transactions.
Well no, that is not necessarily the point of transactions. It is
sufficient to report the error and the calling process can decide whether
to continue the transaction using another approach or to abort it by
calling rollback. The RDBMS should abort a transaction only when it has no
reasonable way to revert to the state before the command that failed.
All major RDBMS systems behave this way, hence one cannot be surprised
when people expect this behaviour also in Postgresql. This was discussed
here several times.
> What would be nice would be nested transactions. Then the drop could
> be placed within its own transaction, and the outer one wouldn't be
> affected.
Nested transactions are more general than statement-level abort in that
they allow users to define the scope of the nested transaction. It is also
the preferred way to cleanly implement statement-level abort.
Joachim
--
work: joachima@realtimeint.com (http://www.realtimeint.com)
private: joachim@kraut.ca (http://www.kraut.ca)