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