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?
Thanks,
Amit