On Thu, Jan 27, 2011 at 1:14 AM, Noah Misch <noah@leadboat.com> wrote:
> Based on downthread discussion, I figure this will all change a good deal. I'll
> still briefly explain the patch as written. Most of the patch is plumbing to
> support the new syntax, catalog entries, and FuncExpr field. The important
> changes are in parse_coerce.c. I modified find_coercion_pathway() and
> find_typmod_coercion_function() to retrieve pg_cast.castexemptor alongside
> pg_cast.castfunc. Their callers (coerce_type() and coerce_type_typmod(),
> respectively) then call the new apply_exemptor_function(), which calls the
> exemptor function, if any, returns the value to place in FuncExpr.funcexempt,
> and possibly updates the CoercionPathType the caller is about to use.
> build_coercion_expression(), unchanged except to populate FuncExpr.funcexempt,
> remains responsible for creating the appropriate node (RelabelType, FuncExpr).
> Finally, I change GetCoerceExemptions to use FuncExpr.funcexempt.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
