On Wed, Mar 14, 2012 at 12:00 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > David Fetter <da...@fetter.org> writes: >> On Wed, Mar 14, 2012 at 11:29:14AM -0400, Tom Lane wrote: >>> The posted patch for file_fdw takes the approach of silently >>> filtering out rows for which they're not true, which is not >>> obviously the right thing either --- quite aside from whether that's >>> a sane semantics, > >> It clearly is for the author's use case. Other use cases will differ. > > You're assuming facts not in evidence. Fujita-san posted that patch not > because he had any use case one way or the other, but because he read > something in fdwhandler.sgml that made him think it was required to > avoid planner malfunctions. (Actually it is not, at the moment, since > we don't do any optimizations based on NOT NULL properties; but we might > in future.) The question on the table is precisely whether believing a > contrary-to-fact NOT NULL assertion would constitute planner malfunction > or user error.
+1 for user error. I think at some point I had taken the view that perhaps the FDW should check the data it's emitting against the NOT NULL constraints, but that would imply that we ought to cross-check CHECK constraints as well, once we have those, which sounds unreasonably expensive. So defining the constraint as a promise by the user seems best. -- 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
