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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
