On 2015/05/18 17:44, Amit Langote wrote:
> On 2015-05-18 PM 05:03, Etsuro Fujita wrote:
>> On 2015/05/16 3:32, Robert Haas wrote:
>>> On Thu, May 14, 2015 at 6:37 AM, Etsuro Fujita
>>> <fujita.etsuro@lab.ntt.co.jp> wrote:
>>>> On second thought, I noticed that as for this option, we cannot live without
>>>> allowing IMPORT FOREIGN SCHEMA to return ALTER FOREIGN TABLE statements
>>>> because we cannot declare the convalidated information in the CREATE FOREIGN
>>>> TABLE statement. So, I think we shoould also allow it to return ALTER
>>>> FOREIGN TABLE statements. Am I right?
>>>
>>> Isn't convalidated utterly meaningless for constraints on foreign tables?
>>
>> 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.
Best regards,
Etsuro Fujita