Re: Foreign key reference causes invalid DELETE trigger calls

From: "Andrus" <eetasoft(at)online(dot)ee>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Foreign key reference causes invalid DELETE trigger calls
Date: 2005-11-09 20:19:53
Message-ID: dktlra$24k4$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> Because you have an ON DELETE CASCADE. That leads to a DELETE ... WHERE
> ...
> on the slave table; whether any records actually get deleted depends on
> what the DELETE finds. This is a general hazard of using STATEMENT
> triggers: you have no info about whether the statement actually did
> anything.

Tom, thank you.

I try to implement table level replication in my application.
Last table change time is written to control table by trigger.
Client finds the tables which are changed after last login and re-loads the
whole tables. Unfortunately, ON DELETE CASCADE tables are replicated always
in this case
which slows down my application startup.

Should I use foo_trig as row level trigger to detect only real row deletion
?

> (It's rather silly to imagine that a BEFORE STATEMENT trigger
> would have any way to know that anyway. We currently don't tell an
> AFTER STATEMENT trigger anything either; though that may change
> someday.)

I tried following code:

insert into klient values (1);
update klient set kood=2 WHERE kood=3;

In this case, foo_trig trigger is NOT executed.

So BEFORE UPDATE ROW trigger is NOT executed when there are no rows to
update,
but BEFORE DELETE ROW trigger IS executed when there are no rows to delete!

Why is this behaviour inconsistent ?

Andrus.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jim C. Nasby 2005-11-09 20:36:47 Re: newbie design question re impact of VACUUM
Previous Message Giovanni M. 2005-11-09 20:18:17 Re: PostgreSQL now() function returns incorrect time