Re: Passing initially_valid values instead of !skip_validation to StoreRelCheck() in AddRelationNewConstraints()

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: amul sul <sul_amul(at)yahoo(dot)co(dot)in>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Passing initially_valid values instead of !skip_validation to StoreRelCheck() in AddRelationNewConstraints()
Date: 2015-12-04 00:49:01
Message-ID: 5660E2FD.2030105@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015/12/03 20:44, amul sul wrote:
>> On Thursday, 3 December 2015 4:36 PM, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> Especially from a readability standpoint, I think using skip_validation may be more apt.
>> Why - the corresponding parameter of StoreRelCheck() dictates what's stored in pg_constraint.convalidated.
>
> Why not? won't initially_valid flag serve same purpose ?

Yes it could, but IMO, it wouldn't be a readability improvement. As I
said, you could think of the variable/argument as delivering whether the
clause is marked NOT VALID or not. Also, see below.

>
>> So, if skip_validation is 'true' because user specified the constraint NOT VALID,
>> StoreRelCheck() will store the constraint with convalidated as 'false'
>
> I guess thats was added before initially_valid flag. As I said, in normal case gram.y take care of skip_validation & initially_valid values, if one is 'true' other will be 'false'.
>
>> The user will have to separately validate the constraint by issuing a ALTER TABLE VALIDATE CONSTRAINT
>> command at a time of their choosing.
>
>
> This could be time consuming operation for big table, If I am pretty much sure that my constraint will be valid, simply I could set both flag(initially_valid & skip_validation) to true.

There is currently no support for adding a constraint after-the-fact (that
is, using ALTER TABLE) and marking it valid without actually verifying it
by scanning the table. As Marko points out that would be actually a new
SQL-level feature that requires much more than changing that line.

Thanks,
Amit

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2015-12-04 02:21:55 Re: eXtensible Transaction Manager API
Previous Message Robert Haas 2015-12-03 22:41:49 Re: eXtensible Transaction Manager API