Re: Referential integrity vulnerability in 8.3.3

From: Richard Huxton <dev(at)archonet(dot)com>
To: Sergey Konoplev <gray(dot)ru(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Referential integrity vulnerability in 8.3.3
Date: 2008-07-15 12:00:42
Message-ID: 487C916A.1090505@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Sergey Konoplev wrote:
> There is an oddity (or a bug) in situation with returning null before
> delete trigger and referential integrity in PG 8.3.3. I tryed to find
> a solution in Google and PG documentation and have noticed nothing
> useful.
[snip]
> CREATE OR REPLACE FUNCTION tr_stop()
> RETURNS trigger AS
> $BODY$begin
> return null;
> end;$BODY$
> LANGUAGE 'plpgsql' VOLATILE;
>
> CREATE TRIGGER tr_stop
> BEFORE DELETE
> ON table2
> FOR EACH ROW
> EXECUTE PROCEDURE tr_stop();
[snip]
> Now comming to a head. As I supposed earlier, deletion from table1 has
> to be prevented by referential integrity when the trigger prevents
> deletion of refered row from table2. But it doesn't.
[snip]
> Will you explain me please why PG behave so cos IMHO it's a bit
> illogical. Thanx.

Your trigger doesn't prevent deletion, it just skips the row(s) in
question from being affected. Raise an exception if you want to abort
the transaction.

See the manual - triggers chapter and plpgsql chapter for more details.

--
Richard Huxton
Archonet Ltd

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Morten Barklund 2008-07-15 12:02:55 Unicode database on non-unicode operating system
Previous Message Sergey Konoplev 2008-07-15 11:42:17 Referential integrity vulnerability in 8.3.3