let me put it in other words, is there any harm use of initially_valid instead of !skip_validation?
Earlier to commit I mentioned in my first post, there is only one flag, IMO i.e. skip_validation, which are serving
bothpurpose, setting pg_constraint.convalidated & decide to skip or validate existing data.
Now, if we have two flag, which can separately use for there respective purpose, then why do you think that it is not
readable?
>As Marko points out that would be actually a new
>SQL-level feature that requires much more than changing that line.
May be yes.
Regards, Amul Sul
On Friday, 4 December 2015 6:21 AM, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
On 2015/12/03 20:44, amul sul wrote:
>> On Thursday, 3 December 2015 4:36 PM, Amit Langote <Langote_Amit_f8@lab.ntt.co.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_validvalues, 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,
simplyI 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers