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

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.

regards, tom lane