On 2015-05-18 PM 06:45, Etsuro Fujita wrote:
> On 2015/05/18 17:44, Amit Langote wrote:
>> On 2015-05-18 PM 05:03, Etsuro Fujita wrote:
>>> Let me explain. I think that convalidated would be *essential* for accurately
>>> performing relation_excluded_by_constraints for foreign tables like plain
>>> tables; if we didn't have that information, I think we would fail to
>>> accurately detect whether foreign tables need not be scanned.
>
>> So, if we decide to reflect remote/accurate convalidated locally by using the
>> method you propose then would it mean only the foreign tables imported using
>> IMPORT FOREIGN SCHEMA will have accurate convalidated info? AFAICS, there is
>> no way to ensure the same for foreign tables created in normal way (CREATE
>> FOREIGN TABLE) nor is there a way to propagate ALTER TABLE ... VALIDATE
>> CONSTRAINT on a foreign table to remote side so that convalidated on the local
>> side really matches the reality (on remote side). Does that cause inconsistent
>> behavior or am I missing something?
>
> We now allow ALTER FOREIGN TABLE ADD CONSTRAINT NOT VALID. So after creating
> foreign tables in normal way (CREATE FOREIGN TABLE), we can manually define
> CHECK constraints that have convalidated = false by that command.
>
Ah, so creating a NOT VALID constraint *prevents* potentially wrong exclusion
of a foreign table at least based on that constraint. Thanks for reminding of
that option.
Thanks,
Amit