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 both purpose, 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...@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...@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_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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
