On 2015-05-18 PM 06:45, Etsuro Fujita wrote: > On 2015/05/18 17:44, Amit Langote wrote: >> On 2015-05-18 PM 05:03, Etsuro Fujita wrote: >>> 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? > > We now allow ALTER FOREIGN TABLE ADD CONSTRAINT NOT VALID. So after creating > foreign tables in normal way (CREATE FOREIGN TABLE), we can manually define > CHECK constraints that have convalidated = false by that command. >
Ah, so creating a NOT VALID constraint *prevents* potentially wrong exclusion of a foreign table at least based on that constraint. Thanks for reminding of that option. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
