Last week I said:
>> I think that instead of storing just table names in the trigger
>> parameters, we should store either table OIDs or schema name + table
>> name. [ ... ]
>> So I'm leaning towards OIDs, but wanted to see if anyone had a beef
>> with that.
I've just realized that if we change the RI trigger arguments this way,
we will have a really serious problem with accepting pg_dump scripts
from prior versions. The scripts' representation of foreign key
constraints will contain commands like
CREATE CONSTRAINT TRIGGER "<unnamed>" AFTER UPDATE ON "bar" FROM "baz" NOT DEFERRABLE INITIALLY IMMEDIATE FOR EACH ROW
EXECUTEPROCEDURE "RI_FKey_noaction_upd" ('<unnamed>', 'baz', 'bar', 'UNSPECIFIED', 'f1', 'f1');
which will absolutely not work at all if the 7.3 triggers are expecting
to find OIDs in those arguments.
I thought about allowing the triggers to take qualified names in the
style of what nextval() is doing in current sources, but that's still
going to have a lot of nasty compatibility issues --- mixed-case
names, names containing dots, etc are all going to be interpreted
differently than before.
I think we may have little choice except to create two sets of RI trigger
procedures, one that takes the old-style arguments and one that takes
new-style arguments. However the old-style set will be horribly fragile
because they'll have to interpret their arguments based on the current
namespace search path.
Of course the *real* problem here is that pg_dump is outputting a
low-level representation of the original constraints. We knew all along
that that would get us into trouble eventually ... and that trouble is
now upon us. We really need to fix pg_dump to emit ALTER TABLE ADD
CONSTRAINT type commands instead of trigger definitions.
A possible escape from the dilemma is to fix pg_dump so that it can emit
ADD CONSTRAINT commands when it sees RI triggers, release that in 7.2.2,
and then *require* people to use 7.2.2 or later pg_dump when it comes
time to update to 7.3. I do not much like this ... but it may be better
than the alternative of trying to maintain backwards-compatible
triggers.
Comments? Better ideas?
regards, tom lane