Re: Suggested TODO: allow ALTERing of typemods without heap/index rebuild

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

In response to

Browse pgsql-hackers by date

  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