On 2015/05/22 1:36, Robert Haas wrote:
On Mon, May 18, 2015 at 4:03 AM, Etsuro Fujita
<fujita.ets...@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.ets...@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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to