On Wed, Mar 14, 2012 at 12:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> David Fetter <david@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
