From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Peter Koczan" <pjkoczan(at)gmail(dot)com> |
Cc: | "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Legacy foreign keys |
Date: | 2008-02-01 23:53:00 |
Message-ID: | 17999.1201909980@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
"Peter Koczan" <pjkoczan(at)gmail(dot)com> writes:
> I have a theory as to what's happening. It can find both tables The
> new smarts in the 8.3 server seem to require a "complete" foreign key,
> which, I'm guessing, would require additional triggers defining
> RESTRICT or CASCADE on UPDATEs and DELETEs.
Yeah, it's expecting to see a set of three related triggers. For
instance, if I do this in a 7.0 database:
play=> create table master(f1 int primary key);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'master_pkey' for table 'master'
CREATE
play=> create table slave(ff int references master);
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s)
CREATE
and then pg_dump it, I get these three triggers:
--
-- Name: RI_ConstraintTrigger_4583989; Type: TRIGGER; Schema: public; Owner: tgl
--
CREATE CONSTRAINT TRIGGER "<unnamed>"
AFTER INSERT OR UPDATE ON slave
FROM master
NOT DEFERRABLE INITIALLY IMMEDIATE
FOR EACH ROW
EXECUTE PROCEDURE "RI_FKey_check_ins"('<unnamed>', 'slave', 'master', 'UNSPECIFIED', 'ff', 'f1');
--
-- Name: RI_ConstraintTrigger_4583991; Type: TRIGGER; Schema: public; Owner: tgl
--
CREATE CONSTRAINT TRIGGER "<unnamed>"
AFTER DELETE ON master
FROM slave
NOT DEFERRABLE INITIALLY IMMEDIATE
FOR EACH ROW
EXECUTE PROCEDURE "RI_FKey_noaction_del"('<unnamed>', 'slave', 'master', 'UNSPECIFIED', 'ff', 'f1');
--
-- Name: RI_ConstraintTrigger_4583993; Type: TRIGGER; Schema: public; Owner: tgl
--
CREATE CONSTRAINT TRIGGER "<unnamed>"
AFTER UPDATE ON master
FROM slave
NOT DEFERRABLE INITIALLY IMMEDIATE
FOR EACH ROW
EXECUTE PROCEDURE "RI_FKey_noaction_upd"('<unnamed>', 'slave', 'master', 'UNSPECIFIED', 'ff', 'f1');
If your original database doesn't have all three triggers, then you had
a problem already --- the FK constraint wasn't being enforced properly.
> The other problem is that other legacy FK triggers on that same table
> have the same value for the first field, "<unnamed>", which will cause
> name conflicts.
There's a hack to deal with that in the conversion code --- it'll assign
a generated name instead.
> One more thing. Is there any way to quickly find all the old-style
> FKs? I tried looking in pg_trigger but it appears that even new,
> legitimate foreign keys have triggers driving them.
In 8.3, you could look for the pg_trigger entries with zero tgconstraint
values. However, prior versions don't have that column; you'd have to
look instead for entries that aren't linked to a pg_constraint entry
by a pg_depend entry.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Koczan | 2008-02-02 19:43:15 | Re: Legacy foreign keys |
Previous Message | Peter Koczan | 2008-02-01 23:39:13 | Re: Legacy foreign keys |