Re: FK NOT VALID can't be deferrable?

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FK NOT VALID can't be deferrable?
Date: 2011-06-15 19:08:58
Message-ID: BANLkTimMveWcbo_iMs3N8w27qovJs2zw5g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 15, 2011 at 4:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
>> On 15 June 2011 07:56, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
>>> Testing the CHECK NOT VALID patch i found $subject... is this intended?
>
>> Aside from the ugliness of the code, we can't just add a
>> ConstraintAttributeSpec to the second block, because that would
>> enforce an order to these options.
>
>> OTOH adding NOT VALID to ConstraintAttributeSpec is a bit invasive,
>> since it's used in quite a few places, including CREATE TABLE, where
>> NOT VALID is never allowed.
>
>> Thoughts?
>
> I think we need to do the second one, ie, add it to
> ConstraintAttributeSpec and do what's necessary to filter later.
> The reason we have a problem here is exactly that somebody took
> shortcuts.

There were grammar issues in the NOT VALID patch which I sought to
resolve. Those new suggestions may fall foul of the same issues.

I raised that point and asked for input prior to commit.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martin Pihlak 2011-06-15 19:20:34 Re: libpq SSL with non-blocking sockets
Previous Message Tom Lane 2011-06-15 19:05:40 Re: Strict Set Returning Functions