Re: Teaching pg_dump to use NOT VALID constraints - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Teaching pg_dump to use NOT VALID constraints
Date
Msg-id 20141114143711.GK1791@alvin.alvh.no-ip.org
Whole thread Raw
In response to Re: Teaching pg_dump to use NOT VALID constraints  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut wrote:
> On 11/13/14 5:07 AM, Simon Riggs wrote:
> > On 13 November 2014 00:20, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> > 
> >> Isn't the real use-case here that if constraints were valid when you dumped
> >> then we shouldn't have to *any* re-validate when we load? (Though, we'd have
> >> to be careful of that with CHECK because that can call user code...)
> > 
> > Yes, that is the use case this patch would improve considerably.
> 
> But your patch doesn't really address that.  It just leaves the
> constraints as invalid, and someone will have to revalidate them later
> (how?).  What Jim was describing was a mode that creates the constraints
> as valid but doesn't actually validate them.  I can see both sides of
> that kind of feature.

This might lead to users introducing invalid data by way of declaring
constants as valid but not checked by the system; if they turn out to be
invalid, the final state is a mess.  I would only buy such a feature if
we had some way to pass down the knowledge of the constraint being valid
in the original system through some other means; say emit a CRC of the
copy data in the pg_dump output that can be verified while loading, and
only allow unvalidated constraints to be marked VALID if the sum
matches.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Customized Options Threshold Error
Next
From: Tom Lane
Date:
Subject: Re: EXPLAIN ANALYZE output weird for Top-N Sort