On Mon, Jun 13, 2011 at 9:41 PM, Alvaro Herrera <alvhe...@commandprompt.com> wrote: > Excerpts from Josh Berkus's message of lun jun 13 18:11:54 -0400 2011: >> Alvaro, Dean, >> >> >> I think that you also need to update the constraint exclusion code >> >> > (get_relation_constraints() or nearby), otherwise the planner might >> >> > exclude a relation on the basis of a CHECK constraint that is not >> >> > currently VALID. >> > Ouch, yeah, thanks for pointing that out. Fortunately the patch to fix >> > this is quite simple. I don't have it handy right now but I'll post it >> > soon. >> >> Hmmm. Is this the behavior we want with NOT VALID constraints though? >> >> I know that if I'm pouring 100m rows into a new partition as part of a >> repartitioning scheme, I don't want to *ever* check them if I know >> they're correct because of how I created the table (CREATE TABLE AS ...). > > Well, if we don't validate the data, it's an open door for potentially > corrupt query results. I'm not really sure that we want to provide > support for "I don't ever want to check this data for validity" because > of that. But then, I just work here.
At any rate, we can't very well have two different meanings for NOT VALID, so the 9.2 meaning vis-a-vis CHECK constraints had better match the 9.1 behavior vis-a-vis FOREIGN KEYs. -- 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
