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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
