On Thu, Jan 27, 2011 at 09:02:26AM -0500, Robert Haas wrote:
> OK. I was thinking that instead moving this into
> eval_const_expressions(), we just make the logic in
> find_coercion_pathway() call the "exemptor" function (or whatever we
> call it) right around here:
>
> switch (castForm->castmethod)
> {
> case COERCION_METHOD_FUNCTION:
> result = COERCION_PATH_FUNC;
> *funcid = castForm->castfunc;
> break;
> case COERCION_METHOD_INOUT:
> result = COERCION_PATH_COERCEVIAIO;
> break;
> case COERCION_METHOD_BINARY:
> result = COERCION_PATH_RELABELTYPE;
> break;
> default:
> elog(ERROR, "unrecognized
> castmethod: %d",
> (int) castForm->castmethod);
> break;
> }
>
> If it's COERCION_METHOD_FUNCTION, then instead of unconditionally
> setting the result to COERCION_PATH_FUNC, we inquire - based on the
> typemods - whether it's OK to downgrade to a
> COERCION_PATH_RELABELTYPE. The only fly in the ointment is that
> find_coercion_pathway() doesn't current get the typemods. Not sure
> how ugly that would be to fix.
Basically, this is a stylistic variation of the approach from my original at3
patch. I believe I looked at that particular positioning and decided that the
extra arguments and effects on non-parse_coerce.c callers were undesirable.
Debatable as any style issue, though. Note that you need to do the same thing
in find_typmod_coercion_function().
