On Mon, Aug 20, 2012 at 3:56 PM, Jeff Davis <pg...@j-davis.com> wrote: > On Fri, 2012-08-17 at 15:44 -0400, Robert Haas wrote: >> On Fri, Aug 17, 2012 at 2:58 PM, Alvaro Herrera >> <alvhe...@2ndquadrant.com> wrote: >> > I mean, what are NOT NULL in foreign tables for? Are they harmed or >> > helped by having pg_constraint rows? >> >> As I've mentioned when this has come up before, I think that >> constraints on foreign tables should be viewed as declarative >> statements about the contents of the foreign data that the DB will >> assume true. This could be useful for a variety of purposes: >> constraint exclusion, query optimization, etc. > > There are at least three kinds of constraint enforcement: > > 1. Enforced before the query runs (e.g. the current behavior on a normal > table). > > 2. Enforced when the query runs by validating the constraint as you go, > and then throwing an error when it turns out to be false. > > 3. Don't make any attempt to enforce, and silently produce wrong results > if it's false. > > Which are you proposing, and how will the user know which kind of > constraint they've got?
I'm proposing #1 for regular tables, as has always been the case, and #3 for foreign tables. #1 is not a reasonable alternative for foreign tables because we lack enforcement power in that case, 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
