Re: Re: [GENERAL] Forcefully adding a CHECK constrained

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Catalin(ux) M(dot) Boie <catab(at)embedromix(dot)ro>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Re: [GENERAL] Forcefully adding a CHECK constrained
Date: 2012-05-28 16:55:16
Message-ID: 8014.1338224116@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"=?utf-8?B?Q2F0YWxpbih1eCkgTS4gQm9pZQ==?=" <catab(at)embedromix(dot)ro> writes:
> I hope I make myself clear now: I want a possibility to add a CHECK that will be used for partitioning without having to read all data for validation.

Basically, this is unlikely to be accepted, because it does not conform
with the project's worldview.

If you are intent on being smarter than the database is, you could
probably create a NOT VALID constraint and then manually poke the system
catalogs to mark it as valid. Then, when (not if) you make a mistake,
you will have only yourself to blame.

A patch that would stand some chance of getting accepted would be one
that would act like CREATE INDEX CONCURRENTLY: create the constraint as
NOT VALID (so it's getting enforced against new rows), then in
background scan all the existing rows to make sure they meet the
constraint too, then finally mark the constraint VALID. But we don't
consider that second step to be optional.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2012-05-28 17:01:12 Re: PostgreSQL reclaiming table space
Previous Message Karl Denninger 2012-05-28 16:53:35 Re: Attempting to do a rolling move to 9.2Beta (as a slave) fails