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
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 |