Re: CREATE FOREGIN TABLE LACUNA

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CREATE FOREGIN TABLE LACUNA
Date: 2012-03-14 16:27:52
Message-ID: CA+Tgmobj-S-6qkwtb7wftqYO6bZ7R-XhXsxjTFQx2b5X6BZKeg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-03-14 17:23:14 Re: foreign key locks, 2nd attempt
Previous Message Ronan Dunklau 2012-03-14 16:25:24 Re: CREATE FOREGIN TABLE LACUNA