On Mon, 1 Apr 2002, Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Christopher Kings-Lynne wrote:
> >> Why can't we just hack up the CREATE CONSTRAINT TRIGGER code to look up
> >> the OIDs, etc. for the arguments and convert them internally to an ALTER
> >> TABLE/ADD CONSTRAINT or whatever...
>
> > And what language hack do you suggest to suppress the
> > complete referential check of the foreign key table at ALTER
> > TABLE ... time?
>
> Actually, I was interpreting his idea to mean that we add intelligence
> to CREATE TRIGGER to adjust the specified trigger arguments if it sees
> the referenced trigger procedure is one of the RI triggers. It'd be
> fairly self-contained, really, since the CREATE TRIGGER code could use
> its "ON table" and "FROM table" arguments to derive the correct OIDs
> to insert. This could be done always (whether the incoming arguments
> look like OIDs or not), which'd also give us a short-term answer for
> dumping/reloading 7.3-style RI triggers. I'd still like to change
> pg_dump to output some kind of ALTER command in place of CREATE TRIGGER,
> but we'd have some breathing room to debate about how.
>
> I'm now inclined to leave the attribute arguments alone (stick to names
> not numbers) just to avoid possible conversion problems there.
Well, there is another place where the current name behavior
causes problems so we'd need to be sticking in the fully qualified
name, otherwise creating a table in your search path earlier than
the intended table would break the constraint. This currently already
happens with temp tables.
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
