Re: Foreign keys for non-default datatypes, redux

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Foreign keys for non-default datatypes, redux
Дата
Msg-id 27284.1171145094@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Foreign keys for non-default datatypes, redux  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Ответы Re: Foreign keys for non-default datatypes, redux  ("Joshua D. Drake" <jd@commandprompt.com>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: XML export
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Foreign keys for non-default datatypes, redux