Re: ALTER TYPE 3: add facility to identify further no-work cases

Noah Misch <noah@leadboat.com> writes:
> On Wed, Jan 26, 2011 at 05:55:37PM -0500, Tom Lane wrote:
>> Actually, I can construct a concrete example where applying this
>> optimization in the parser will do the wrong thing:
>> 
>> 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);
>> 
>> If the parser is taught to throw away "useless" length coercions, then
>> the stored form of vv will contain no cast, and the results will be
>> wrong after base's column is widened.

> We reject that:

> [local] test=# ALTER TABLE base ALTER COLUMN f1 TYPE varchar(16);
> ERROR:  cannot alter type of a column used by a view or rule
> DETAIL:  rule _RETURN on view vv depends on column "f1"

Nonetheless, the stored form of vv will contain no cast, which can
hardly be thought safe here.  Relaxing the restriction you cite is (or
should be) on the TODO list, but we'll never be able to do it if the
parser throws away relevant information.
        regards, tom lane