Re: Check Constraints and pg_dump

Поиск
Список
Период
Сортировка
Искать
От
Curt Sampson
Тема
Re: Check Constraints and pg_dump
Дата
Msg-id
Pine.NEB.4.58.0403021049140.13600@angelic-vtfw.cvpn.cynic.net
Ответ на
Список
Дерево обсуждения
Check Constraints and pg_dump Jonathan Scott <jwscott@vanten.com>
Re: Check Constraints and pg_dump Tom Lane <tgl@sss.pgh.pa.us>
Re: Check Constraints and pg_dump Jonathan Scott <jwscott@vanten.com>
Re: Check Constraints and pg_dump Curt Sampson <cjs@cynic.net>
Re: Check Constraints and pg_dump Tom Lane <tgl@sss.pgh.pa.us>
Re: Check Constraints and pg_dump Curt Sampson <cjs@cynic.net>
Re: Check Constraints and pg_dump Robert Treat <xzilla@users.sourceforge.net>
Re: Check Constraints and pg_dump Bruno Wolff III <bruno@wolff.to>
Re: Check Constraints and pg_dump Curt Sampson <cjs@cynic.net>
On Thu, 26 Feb 2004, Tom Lane wrote:

> Jonathan Scott  writes:
> > The functions and tables create just fine, but when it gets to the
> > COPY part of the sql script, it tries to load tables in what really is
> > the wrong order. The check constraint is making sure there is a "plan"
> > before there is a "contract", yet pg_dump is trying to load the
> > contract table before there is anything in the plan table.
>
> Shouldn't you be using a foreign key for that?

Can you explain how to do this? There is no reference to a plan in the
contract table; the constraint just checks to see that, if a contract
exists, there is at least one plan referencing that contract.

There is of course a foreign key constraint used in the plan table to
make sure that the contract exists.

> I don't see any reasonable way that pg_dump can be expected to
> understand that a check constraint expresses a relationship between two
> tables.  The semantics of check constraints aren't right for it anyway.

What other constraint could one use for a situation like this?

At any rate, I am not sure why pg_dump has to know or care what check
constraints do; if it simply treated them as it does all the other
constraints, and applied them after all the data are loaded, wouldn't
the problem just go away?

cjs
-- 
Curt Sampson     +81 90 7737 2974   http://www.NetBSD.org   Don't you know, in this new Dark Age, we're all light.  --XTC

В списке pgsql-hackers по дате отправления
От: Bruno Wolff III
Дата:
От: Rod Taylor
Дата:
FAQ