Re: foreign keys - Mailing list pgsql-general

From Stephan Szabo
Subject Re: foreign keys
Date
Msg-id Pine.BSF.4.10.10008061416270.48386-100000@megazone23.bigpanda.com
Whole thread Raw
In response to Re: foreign keys  (Radoslaw Stachowiak <radek@alter.pl>)
Responses Re: foreign keys  (Radoslaw Stachowiak <radek@alter.pl>)
List pgsql-general
On Sun, 6 Aug 2000, Radoslaw Stachowiak wrote:

> *** Bruce Momjian <pgman@candle.pha.pa.us> [Saturday, 05.August.2000, 19:39 -0400]:
> > > Not to mentions fact that in a few places in docs it's shown as a method
> > > for copying table "SELECT... INTO" which does not "take" keys with it
> > > leading to database knwoledge loss.
> >
> > That is a good point.  SELECT INTO doesn't support constraints.
> > Unfortunately, I don't really know a way around that.  The only solution
> > is CREATE TABLE and then INSERT INTO ... SELECT.
> [.rs.]
>
> what about my other statement about third constraint not being transferred
> withh pg_dump -t table because it was "connected" to second database? Am I right?

Actually, you should only be seeing one constraint out on the referencing
table and two out of the referenced one, but yes, fundamentally it only is
dumping the constraint triggers for the table you are dumping at the
moment.

> What is correct (mean: most simple) way of dupicating table with all FK ?

Umm, possibly taking the dump of the table you want and a schema only
dump of the referenced table and removing the bits you don't need.

Or, turn the constraint triggers into alter table add constraint
statements (although you'd then have to only get one alter table add
constraint in case you were on the referenced table - and that could
still get you in trouble depending on what precisely you're doing --
if the table was the referenced table of a fk constraint, would you
necessarily want to alter the table that was referencing it?).



pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: foreign keys
Next
From:
Date:
Subject: Re: foreign keys