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" -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
