From: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
---|---|
To: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: pg_restore and create FK without verification check |
Date: | 2003-11-26 20:32:47 |
Message-ID: | 1069878767.24916.18.camel@camel |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2003-11-26 at 12:43, Andreas Pflug wrote:
> Greg Stark wrote:
>
> >If I could disable and reenable the constraint the danger that I would get the
> >definition wrong would be eliminated. And if I had already done the work to
> >ensure there were no broken relationships I would optionally be able to skip
> >the redundant automatic check. I could even have done the verification myself
> >while the data wasn't live for example.
> >
> >
>
> Since FKs are implemented as trigger, you could disable all triggers on
> the table right now, no? Could be a bit more comfortable, I agree, and
> hope for an upcoming DISABLE TRIGGER command.
ISTM I've done this before... from a pg_dump -Fc backup first do a
pg_dump -s restore (schema only) and then a pg_dump -a
--disable-triggers to load the data without check foreign keys.
Theres certainly potential for trouble with this method I suppose but it
seems like it accomplish what the original poster requires...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2003-11-26 20:33:56 | Re: detecting poor query plans |
Previous Message | Joshua D. Drake | 2003-11-26 19:43:18 | Limiting factors of pg_largeobject |