| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: To-Do item: skip table scan for adding column with provable check constraints |
| Date: | 2016-05-24 22:56:32 |
| Message-ID: | 20169.1464130592@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> ... and if the CHECK expression is immutable ...
> Doesn't it have to be already?
AFAIK we don't insist on that currently. You could imagine useful checks
that are not, for example CHECK(write_timestamp <= now()).
> Otherwise a value accepted at one point in time could suddenly violate
> the constraint later, even though it never changed.
True. If you use a non-immutable check, it's on your head whether or not
this is a problem. But the database shouldn't perform optimizations that
just assume it's immutable without checking.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2016-05-24 23:13:04 | Re: [sqlsmith] PANIC: failed to add BRIN tuple |
| Previous Message | Tom Lane | 2016-05-24 22:52:19 | Re: statistics for shared catalogs not updated when autovacuum is off |