From: | Greg Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Suggested TODO: allow ALTERing of typemods without heap/index rebuild |
Date: | 2009-06-01 21:17:30 |
Message-ID: | 4136ffa0906011417l6f4b1875o8f97207ca78ac592@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 1, 2009 at 9:49 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
>
> NUMERIC(x, y) comes to mind, although that might be a more dangerous
> case. If you turn a NUMERIC(5,0) into a NUMERIC(5,1), then '1.2' may be
> stored as either '1' or '1.2' depending on whether you did the insert
> before or after the change. That's because, with NUMERIC, it's not
> really a constraint, but a rule for rounding.
Well it's not like rewriting the table is going to accomplish anything though...
> There may be other interesting cases involving constraints. For
> instance, if you have CHECK(i < 200), you should be able to add CHECK(i
> < 1000) without an exclusive lock or recheck. Then, with an exclusive
> lock, you can remove the original tighter constraint, but at least it
> wouldn't have to recheck the entire table.
We have the infrastructure for this kind of check actually, it's the
same kind of thing we do for partition exclusion...
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2009-06-01 21:26:43 | Re: User-facing aspects of serializable transactions |
Previous Message | Greg Stark | 2009-06-01 21:12:48 | Re: User-facing aspects of serializable transactions |