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
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 |