On Wed, 24 Jan 2001 00:26:58 -0500 (EST), Michael Fork wrote:
>One other method is to setup up the foreign keys as ON DELETE RESTRICT,
>then outside of your transaction block issue a DELETE FROM address WHERE
>add_id = 1; If there are still records in the other tables referencing
>this record, it will error out and nothing will happen, however if no
>related records are left, the delete will succeed (you have to do it
>outside of transaction, otherwise I belive it will rollback on the
>error if other rows are found to be referencing the primary key)....
Yes, that's the approach I originally posted. The rollback issue is the
thing I'm complaining about. The code in question gets called from within
a parent function, which uses a single transaction block for all of its
operations. This means that executing a query outside a transaction block
(or within a separate one) is not an option.
I want to be able to tell postgres not to rollback the whole transaction
just because my delete attempt fails. I can think of 3 ways to do this:
1. Allow the delete to fail without throwing a fatal error. (Perhaps a
warning would suffice.)
2. Allow the client to tell postgres not to roll back if a specified query
produces an error.
3. Implement nested transactions.
Forest
