On 1 August 2017 at 08:37, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/08/01 15:22, Simon Riggs wrote: >> On 1 August 2017 at 07:16, Amit Langote <langote_amit...@lab.ntt.co.jp> >> wrote: >>> In f27a6b15e656 (9.6 & later), we decided to "Mark CHECK constraints >>> declared NOT VALID valid if created with table." In retrospect, >>> constraints on foreign tables should have been excluded from consideration >>> in that commit, because the thinking behind the aforementioned commit >>> (that the constraint is trivially validated because the newly created >>> table contains no data) does not equally apply to the foreign tables case. >>> >>> Should we do something about that? >> >> In what way does it not apply? Do you have a failure case? > > Sorry for not mentioning the details. > > I was thinking that a foreign table starts containing the data of the > remote object it points to the moment it's created (unlike local tables > which contain no data to begin with). If a user is not sure whether a > particular constraint being created in the same command holds for the > remote data, they may mark it as NOT VALID and hope that the system treats > the constraint as such until such a time that they mark it valid by > running ALTER TABLE VALIDATE CONSTRAINT. Since the planner is the only > consumer of pg_constraint.convalidated, that means the user expects the > planner to ignore such a constraint. Since f27a6b15e656, users are no > longer able to expect so.
For Foreign Tables, it sounds like an issue. Don't think it exists for normal tables. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
