"Peter Koczan" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org