OK, then we should at least forbit making such things... Otherwise, it
seems to be smth like gotcha.
But look at this please:
"12) If <search condition> is specified, then the <search condition> is
evaluated for each row of T prior
invocation of any <triggered action> caused by the imminent or actual
deletion of any row of T."
Does Postgres work this way? In the case of 'delete from tbl;' we
have search condition>=TRUE for all rows. If we evaluate it *before*
any other operation, we should mark all rows to be deleted. I guess,
Postgres doesn't follow this logic..
Am I wrong?
P.S. BTW, look at the -novice list - he reports, that problem remains
even after dropping FK at all.
On 8/2/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Nikolay Samokhvalov" <samokhvalov@gmail.com> writes:
> > Is this a bug or not?
>
> I don't think so --- or perhaps better, this is a buggy trigger.
> he UPDATE in the trigger will supersede the base DELETE query for any
> rows that the UPDATE changes before the base DELETE has reached 'em.
> Essentially you've written an indeterminate system ...
>
> regards, tom lane
>
--
Best regards,
Nikolay