Re: Legacy foreign keys

"Peter Koczan" <pjkoczan@gmail.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