Re: foreign keys
От | Stephan Szabo |
---|---|
Тема | Re: foreign keys |
Дата | |
Msg-id | Pine.BSF.4.10.10008061416270.48386-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: foreign keys (Radoslaw Stachowiak <radek@alter.pl>) |
Ответы |
Re: foreign keys
|
Список | 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 по дате отправления: