> > > I didn't implement the [ FORMAT <cast template> ] part for now. > please check the attached regress test and tests expected result. >
Question about this: +/* + * Push steps to evaluate a SafeTypeCastExpr and its various subsidiary expressions. + * We already handle CoerceViaIO, CoerceToDomain, and ArrayCoerceExpr error + * softly. However, FuncExpr (e.g., int84) cannot be made error-safe. + * In such cases, we wrap the source expression and target type information into + * a CoerceViaIO node instead. + */ I'm not sure we _can_ just fall back to the CoerceViaIO if there is a defined cast from TypeA -> TypeB. I seem to recall there was some reason we couldn't do that, possibly to do with how it handled rounding, but I have no clear memory of it. Aside from that, I like what you've done with making SafeTypeCastExpr be its own node type and not saddling regular typecasts with the overhead.
