On 2015/05/22 1:36, Robert Haas wrote:
> On Mon, May 18, 2015 at 4:03 AM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp> 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.
>
> My point is that any constraint on a foreign table is just something
> we HOPE the remote side is enforcing. Regardless of whether
> convalidated is true or false locally, it could have some other value
> on the remote side, or the constraint might not exist on the remote
> side at all.
I agree with you on that point. And I think one option for that is that
IMPORT FOREIGN SCHEMA only imports CHECK constraints of remote tables
from a remote server that have convalidated = true. (If doing so, we
wouldn't need to allow IMPORT FOREIGN SCHEMA to return ALTER FOREIGN
TABLE statements.) But I'm not sure that that is a good idea. ISTM it
would be better for IMPORT FOREIGN SCHEMA just to imports all CHECK
constraints of remote tables, reflecting convalidated, and that we leave
it to the user to do VALIDATE CONSTRAINT for locally defined constraints
that have convalidated = false when matching constraints are validated
on the remote server.
Best regards,
Etsuro Fujita