Re: Constraint documentation

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Lætitia Avrot <laetitia(dot)avrot(at)gmail(dot)com>,bpd0018(at)gmail(dot)com,vik(dot)fearing(at)2ndquadrant(dot)com,coelho(at)cri(dot)ensmp(dot)fr
Subject: Re: Constraint documentation
Date: 2018-08-10 15:37:26
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On August 10, 2018 7:17:09 PM GMT+05:30, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
>> I think it would be very easy to restore check constraints separately
>> after all tables in pg_dump. There is already support for that, but
>> it's only used when necessary, for things like not-valid constraints.
>> The argument in favor of keeping the constraint with the table is
>> probably only aesthetics,
>No, it's mainly about performance. Checking the constraint at data
>time avoids extra scans of the table, and should work in any case that
>we consider supported.
>To be clear, I totally reject the notion that we should consider this
>case supported, or that kluging pg_dump to not fail would make it so.
>As a counterexample, if you have a poor-mans-FK check constraint on
>table A that only succeeds when there's a matching row in table B, it
>cannot prevent the case where you insert a valid (matching) row in
>table A and then later delete its matching row in B.
>Maybe someday we'll have full database assertions (with, no doubt,
>a ton of performance caveats). In the meantime, let's not slow down
>CHECK constraints for everyone in order to partially fix a
>fundamentally broken use-case. If the documentation isn't clear enough
>about such cases being unsupported, by all means let's make it so.


Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-08-10 16:30:21 Re: Improve behavior of concurrent TRUNCATE
Previous Message David Fetter 2018-08-10 15:36:23 Re: Constraint documentation