Dirk Jagdmann <[EMAIL PROTECTED]> writes:
> Now I'd like to know if the current order of deletions in PostgreSQL
> is intended in the top-down way or if that could be changed?
Sorry, I don't see much chance of changing it.
regards, tom lane
---(end
Hello Tom,
> If you want the whole transaction rolled back, raise an error instead
> of returning NULL.
You're right, that's working. But now I have a slightly different problem.
I assume that the trigger which watches the cascaded deletions first
deletes the row in the monitored table and then
Dirk Jagdmann <[EMAIL PROTECTED]> writes:
> The idea behind the sample commands below is, that the whole deletion
> should be denied, because a trigger in a cascaded table blocked the
> deletion. The trigger works as expected and prevents rows with a value
> of "5" being deleted from table "b". How
Hello,
I often create foreign keys with "on delete cascade" so I can
conviniently delete rows in multiple tables which are referenced by (a
chain) of foreign keys. Now I've run into an issue and I'd like to
have some opinions if the current behaviour of PostgreSQL is desired.
If have made my tests
