Horton

Re: creating CHECK constraints as NOT VALID

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Jaime Casanova <jaime@2ndquadrant.com>, Dean Rasheed <dean.a.rasheed@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2011-06-15T18:49:04Z
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

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Robert Haas's message of mi jun 15 12:53:59 -0400 2011:
>> On Wed, Jun 15, 2011 at 12:24 PM, Alvaro Herrera
>> <alvherre@commandprompt.com> wrote:
>>> Hmm, I think this means we need to send a sinval message to invalidate
>>> cached plans when a constraint is validated.  I'll see about this.

>> I feel like that really ought to be happening automatically, as a
>> result of committing the transaction that did the system catalog
>> modification.  It seems pretty strange if it isn't.

> The catalog change takes place in pg_constraint, so I'm not sure that
> it'd cause the sort of event we need.  I'm testing whether adding a call
> to CacheInvalidateRelcache in the appropriate place works.

Currently, only updates in pg_class, pg_attribute, and pg_index cause
automatic relcache invalidations --- see the logic in
PrepareForTupleInvalidation.  If you want to force replanning after an
update elsewhere, you need to call CacheInvalidateRelcache.  I've
occasionally thought about extending the number of cases that get
handled automatically by PrepareForTupleInvalidation, but not gotten off
my duff to change it.  I doubt that we want to make that routine know
about *every* possible case, so it's a matter of tradeoffs ...

			regards, tom lane