Re: FK constraints "NOT VALID" by default?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: FK constraints "NOT VALID" by default?
Date: 2011-03-18 13:39:58
Message-ID: AANLkTi=qR0zy5cS98n=TDCxda5sj=NODDA=xAZUCdJOE@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 17, 2011 at 5:32 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Mar 17, 2011 at 5:29 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>> Is this really intended?
>>
>> I sure hope not.
>
> That's a bug.  Not sure if it's a psql bug or a backend bug, but it's
> definitely a bug.

It's a backend bug. Prior to Simon's patch, there was an existing
skip_validation flag in the Constraint node that indicated whether or
not a validation pass was necessary - in a newly created table, for
example, we know that it's NOT necessary, because the table can't
contain any rows (and therefore there can't be any rows that violate
the constraint). The patch tries to make the very same flag indicate
whether the user wants the constraint to be added with the NOT VALID
attribute, which of course falls over because the Boolean only has two
values and there are three cases (validate it, don't validate it but
do mark it valid because the table is guaranteed to be empty, don't
validate it and mark it not valid).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-03-18 13:40:22 Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous Message Robert Haas 2011-03-18 13:30:56 Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.