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

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