Re: Foreign keys for non-default datatypes, redux - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Foreign keys for non-default datatypes, redux
Date
Msg-id 27284.1171145094@sss.pgh.pa.us
Whole thread Raw
In response to Re: Foreign keys for non-default datatypes, redux  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Responses Re: Foreign keys for non-default datatypes, redux  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> On Fri, 9 Feb 2007, Tom Lane wrote:
>> I am pretty strongly tempted to stop storing anything in tgargs for RI
>> triggers --- it's ugly, and updating the info during RENAME commands
>> is a pain in the rear.

> I'd say we probably want to keep the tgargs info for at least a version or
> two after changing the implementation.  Getting rid of using the args info
> sounds like a good idea.

After digging around in the code for awhile I realized that there's a
potentially bigger backwards-compatibility issue here: if we make the
RI triggers dependent on finding a pg_constraint entry, then foreign
key constraints loaded from dumps from pre-7.3 databases will no longer
work.  Those dumps just contain "CREATE CONSTRAINT TRIGGER" commands
which will not provide enough information.  We can make the triggers
throw errors suggesting that the user drop the triggers and perform
ALTER TABLE ADD CONSTRAINT.  Is that enough, or do we need to try
harder?

It would probably be possible to teach pg_dump to cons up ADD CONSTRAINT
commands when dumping from an old server, but I think it would be a lot
of work (certainly we punted on that idea back in the 7.3 devel cycle)
and I'm not sure there are enough people running pre-7.3 PG for it to
be worth the effort to provide an automated solution.

Comments?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: XML export
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Foreign keys for non-default datatypes, redux