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

On Wed, Jan 26, 2011 at 05:32:00PM -0500, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > Well, if you're positive we're eventually going to want this in
> > pg_proc, we may as well add it now.  But I'm not too convinced it's
> > the right general API.  The number of people writing exactly x + 0 or
> > x * 0 in a query has got to be vanishingly small; I'm not eager to add
> > additional parse analysis time to every SQL statement that has a
> > function in it just to detect those cases.
> 
> Actually, you've got that backwards: the facility I've got in mind would
> cost next to nothing when not used.  The place where we'd want to insert
> this in eval_const_expressions has already got its hands on the relevant
> pg_proc row, so checking for a nonzero hook-function reference would be
> a matter of a couple of instructions.  If we go with a pg_cast entry
> then we're going to have to add a pg_cast lookup for every cast, whether
> it turns out to be optimizable or not; which is going to cost quite a
> lot more.  The intermediate hook function I was sketching might be
> worthwhile from a performance standpoint even if we don't expose the
> more general feature to users, just because it would be possible to
> avoid useless pg_cast lookups (by not installing the hook except on
> pg_proc entries for which there's a relevant CAST WHEN function to call).

If we hook this into eval_const_expressions, it definitely seems cleaner to
attach the auxiliary function to the pg_proc.  Otherwise, we'd reconstruct which
cast led to each function call -- is there even enough information available to
do so unambiguously?  Unlike something typmod-specific, these functions would
effectively need to be written in C.  Seems like a perfectly acceptable
constraint, though.

For the syntax, then, would a new common_func_opt_item of "WHEN func" fit?

That covers fully-removable casts, but ALTER TABLE still needs to identify casts
that may throw errors but never change the value's binary representation.  Where
does that fit?  Another pg_proc column for a function called to answer that
question, called only from an ALTER TABLE-specific code path?

Thanks for the feedback/analysis.

nm