On Mon, 2012-08-20 at 16:50 -0400, Robert Haas wrote:
> #3 for foreign tables.
I'm skeptical of that approach for two reasons:
(1) It will be hard to inform users which constraints are enforced and
which aren't.
(2) It will be hard for users to understand the planner benefits or the
consequences when the constraint is not enforced.
That being said, I can imagine good use cases (like when the foreign
table is in postgres, and already has that constraint declared), so I'm
not outright opposed to it.
> #1 is not a reasonable alternative for foreign
> tables because we lack enforcement power in that case,
Right.
> and #2 is also
> not reasonable, because the only point of allowing declarative
> constraints is to get better performance, and if we go with #2 then
> we've pretty much thrown that out the window.
Declared constraints can improve the plans, while runtime-enforced
constraints slow down execution of a given plan. I'm not really sure
whether runtime enforcement is a good trade-off, but it doesn't seem
like an obviously bad one.
Also, what did you mean by "the only point of allowing declarative
constraints is to get better performance"? Maybe the user wants to get
an error if some important assumption about the remote data source is
not as true as when they declared the constraint.
Regards,Jeff Davis
