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.
