Thread: 9.1 - rewrite less alter table?

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

In commit log I see information about "binary coercible" (which doesn't
mean much to me) - so I assumed varchars() can work this way.

What am I missing?

Best regards,

depesz

--
The best thing about modern society is how easy it is to avoid contact with it.
                                                             http://depesz.com/

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

On Tue, Mar 08, 2011 at 10:43:55PM -0500, Noah Misch wrote:
> 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.

ah, that explains it, thanks.

> 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.
> The applicable definition of "binary coercible" appears in our CREATE CAST
> documentation.

thanks a lot for explanation. much clearer now.

Best regards,

depesz

--
The best thing about modern society is how easy it is to avoid contact with it.
                                                             http://depesz.com/