From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | hubert depesz lubaczewski <depesz(at)depesz(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: 9.1 - rewrite less alter table? |
Date: | 2011-03-09 03:43:55 |
Message-ID: | 20110309034355.GA25985@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, Mar 05, 2011 at 12:55:18PM +0100, hubert depesz lubaczewski wrote:
> perhaps I misunderstood something from commits, but I assumed that in
> 9.1 this operation shouldn't rewrite the table:
>
> CREATE TABLE test ( x varchar(16) );
> insert into test select i::text from generate_series(1,1000000) i;
> alter table test alter column x set data type varchar(32);
>
> but it does.
The patch optimizing that case foundered. We may have it in 9.2.
The current code only kicks in when the destination has no typmod. When the
source/destination type pair are marked "(binary coercible)" in the output of
\dC, the optimization applies. Alternately, it applies when one of the types is
a constraint-free domain over the other.
The practical use cases are a bit thin at present. The main interesting ones
are varchar(N) -> text and conversions between domains and their base types. We
did these first because they required a proper subset of the code needed to
support the more-common cases.
> In commit log I see information about "binary coercible" (which doesn't
> mean much to me) - so I assumed varchars() can work this way.
The applicable definition of "binary coercible" appears in our CREATE CAST
documentation.
nm
From | Date | Subject | |
---|---|---|---|
Next Message | abcdef | 2011-03-09 04:26:54 | procedure in db |
Previous Message | Darren Duncan | 2011-03-09 01:52:33 | Re: equivalent of mysql's SET type? |