Re: pg_dump restore time and Foreign Keys - Mailing list pgsql-hackers

From Robert Treat
Subject Re: pg_dump restore time and Foreign Keys
Date
Msg-id 200806091237.49153.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: pg_dump restore time and Foreign Keys  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump restore time and Foreign Keys  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On Monday 09 June 2008 11:59:27 Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > On Mon, 2008-06-09 at 11:33 -0400, Tom Lane wrote:
> >> No, we are running a large query to which the user *thinks* he knows the
> >> answer.  There are any number of reasons why he might be wrong.
> >
> > Of course. I should have said "to which we already know the answer" to
> > indicate I'm passing on others' criticisms of us.
>
> [ shrug... ]  We don't know the answer either, and anyone who says
> we do is merely betraying his ignorance of the number of ways to load
> a foot-gun.
>

I think the more realistic scenario (based on the FK idea) is that you want to 
prevent any future rows from coming without validating the FK, and you're 
willing to clean up any violators after the fact, since you can make that 
an "out of the critical path" operation.

if you extend this to a more general "create constraint concurrently" (to 
handle normal constraint, not null constraints, etc...), it would certainly 
be a big win, and i think most would see it as a reasonable compromise. 

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Strange issue with GiST index scan taking far too long
Next
From: Andrew Dunstan
Date:
Subject: Re: proposal: new contrib module - session variables