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
