On Wed, Mar 14, 2012 at 5:14 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On ons, 2012-03-14 at 16:44 -0400, Tom Lane wrote:
>> On reflection I don't see anything much wrong with the "if you lied
>> about the constraint it's your fault that things broke" position.
>> It seems quite comparable to the fact that we take the user's
>> assertions on faith as to the number and data types of the columns in
>> a foreign table.
>
> We do enforce the data types of a foreign table. We can't ensure that
> the data that a foreign table "contains" is valid at any moment, but
> when we read the data and interact with it in SQL, we reject it if it's
> not valid. Similarly, one could conceivably apply not-null and check
> constraints as the data is read, which is exactly what the other patch
> you referred to proposes. And I think we must do it that way, otherwise
> check constraints on domains and check constraints on tables would
> behave quite differently.
>
> So if we want to have fake constraints on foreign tables, I think we
> should require the NOT ENFORCED decoration or something similar, unless
> the FDW signals that it can enforce the constraint.
I think that would be missing the point. If a constraint is NOT
ENFORCED, then the query planner presumably won't rely on it for
planning purposes, but the whole point of having constraints on
foreign tables is that we want the query planner to do just that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
