From: | "Rod Taylor" <rbt(at)zort(dot)ca> |
---|---|
To: | "Hackers List" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Foreign Key & Rule confusion WAS: Lost Trigger(s)? |
Date: | 2001-04-05 23:27:45 |
Message-ID: | 014301c0be28$0552dde0$2205010a@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Found the issue. Try out the attached SQL in a fresh database.
I had honestly expected the second delete to work properly as nothing
had to be removed that table.
The rule was added as a temporary measure to protect the data
currently in the table -- without the intent of otherwise impeding the
other informations use. I suppose I forgot that the table wouldn't be
looked at as the rule is checked quite early.
CREATE TABLE junk_parent (
col SERIAL PRIMARY KEY
);
INSERT INTO junk_parent DEFAULT VALUES;
INSERT INTO junk_parent DEFAULT VALUES;
INSERT INTO junk_parent DEFAULT VALUES;
CREATE TABLE junk (
col int4 NOT NULL REFERENCES junk_parent(col) ON UPDATE CASCADE ON
DELETE CASCADE
);
INSERT INTO junk VALUES ('1');
DELETE FROM junk_parent WHERE col = 1;
DELETE FROM junk_parent WHERE col = 2;
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
Attachment | Content-Type | Size |
---|---|---|
Taylor, Rod B.vcf | text/x-vcard | 451 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2001-04-05 23:29:56 | Foreign Key & Rule confusion RE: Lost Trigger(s)? |
Previous Message | Rod Taylor | 2001-04-05 23:16:49 | INSERT Issues |