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

On Wed, Jan 26, 2011 at 05:55:37PM -0500, Tom Lane wrote:
> I wrote:
> > ... Another issue is that premature
> > optimization in the parser creates headaches if conditions change such
> > that a previous optimization is no longer valid --- you may have stored
> > rules wherein the optimization was already applied.  (Not sure that
> > specific issue applies to casting, since we have no ALTER CAST commmand;
> > but in general you want expression optimizations applied downstream from
> > the rule rewriter not upstream.)
> 
> 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"