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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Noah Misch <noah@leadboat.com>, pgsql-hackers@postgresql.org
Date: 2011-01-26T22:41:44Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Oh, really?  I was thinking the logic should go into find_coercion_pathway().

Well, I've been saying right along that it should be in
eval_const_expressions.  Putting this sort of optimization in the parser
is invariably the wrong thing, because it fails to catch all the
possibilities.  As an example, inlining a SQL function could expose
opportunities of this type.  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.)

			regards, tom lane