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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Nikolay Samokhvalov" <samokhvalov(at)gmail(dot)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
In response to
pgsql-novice by date
|Next:||From: Nikolay Samokhvalov||Date: 2006-08-02 21:06:38|
|Subject: Re: Fwd: [NOVICE] Trigger and Recursive Relation ?|
|Previous:||From: Tom Lane||Date: 2006-08-02 04:10:41|
|Subject: Re: Fwd: [NOVICE] Trigger and Recursive Relation ? |
pgsql-bugs by date
|Next:||From: Luiz Henrique||Date: 2006-08-02 13:58:04|
|Subject: referential integrity violation - key referenced from xxx not found in yyy|
|Previous:||From: tomas||Date: 2006-08-02 05:01:44|
|Subject: Re: pg_restore not work on windows 2000, when dump file size > 4G|