Horton

Re: creating CHECK constraints as NOT VALID

Greg Stark <gsstark@mit.edu>

View thread
From: Greg Stark <gsstark@mit.edu>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: "Ross J. Reedstrom" <reedstrm@rice.edu>, Kevin Grittner <kevin.grittner@wicourts.gov>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2011-05-31T23:03:56Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix pg_get_constraintdef to cope with NOT VALID constraints

On Tue, May 31, 2011 at 1:07 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Ross J. Reedstrom's message of mar may 31 14:02:04 -0400 2011:
>
>> Follows from one of the practical maxims of databases: "The data is
>> always dirty" Being able to have the constraints enforced at least for
>> new data allows you to at least fence the bad data, and have a shot at
>> fixing it all.
>
> Interesting point of view.  I have to admit that I didn't realize I was
> allowing that, even though I have wished for it in the past myself.

What happens when there's bad data that the new transaction touches in
some minor way? For example updating some other column of the row or
just locking the row? What about things like cluster or table
rewrites?

Also I think NOT NULL might be used in the join elimination patch.
Make sure it understands the "valid" flag and doesn't drop joins that
aren't needed. It would be nice to have this for unique constraints as
well which would *definitely* need to have the planner understand
whether they're valid or not.

-- 
greg