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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers