Re: Identifying no-op length coercions

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, May 23, 2011 at 1:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> ... But I remain of the opinion that that's the wrong place
>> to put it.

> So you said here:

> http://archives.postgresql.org/pgsql-hackers/2011-01/msg02575.php
> http://archives.postgresql.org/pgsql-hackers/2011-01/msg02585.php

> The trouble is, I still can't see why type OIDs and typemods should be
> handled differently. Taking your example again:

> CREATE TABLE base (f1 varchar(4));
> CREATE VIEW vv AS SELECT f1::varchar(8) FROM base;
> ALTER TABLE base ALTER COLUMN f1 TYPE varchar(16);

> Your claim on the thread is that we want to someday allow this case.
> But what if the last statement were instead:

> ALTER TABLE base ALTER COLUMN f1 TYPE integer;

> Should it also be our goal to handle that case?

Maybe. But casts would be the least of our concerns if we were trying
to change the column type. Changing typmod doesn't affect the set of
operations that could be applied to a column, whereas changing type
surely does. In any case, the fact that the current implementation can't
readily support that is a poor excuse for building entirely new features
that also can't support it, when said features could easily be designed
without the restriction.

But more generally, I don't believe that you've made any positive case
whatever for doing it from pg_cast. It's not faster, it's not more
flexible, so why should we choose that approach?

regards, tom lane