"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
