core: a user-defined type's parameters are never substituted, so a derived type keeps the parameter name #1313

TypeExpressionEvaluator.evaluateExpression returns a declared return type unchanged when it is already a Type, and the private evaluate helper applies the same shortcut to every sub-expression. ParseToPojo.visitUserDefined produces a Type.UserDefined whose type parameters may be ImmutableType.ParameterStringValue — a parameter name — and Type.UserDefined is a Type, so the shortcut returns it with the name never substituted.

Measured on main at cf581f4, with a declared argument varchar<L> bound to varchar(10):

u!point<L>            ->  UserDefined{name=point, typeParameters=[ParameterStringValue{value=L}], ...}
p = L + 1
u!point<p>            ->  UserDefined{name=point, typeParameters=[ParameterStringValue{value=p}], ...}

The derived type keeps the literal strings L and p instead of 10 and 11, and that serializes into the plan as a string type parameter. In the second case the assignment is evaluated and then discarded.

This is a fail-open, which contradicts the class Javadoc's contract that "The evaluator never falls back to a caller-supplied type: an unresolved expression is an error, not a default". The single-line form predates #1288; the program form threw before it, because ReturnProgram was unsupported, so that shape moved from fail-closed to a silent wrong answer.

No shipped catalog declaration parameterizes a user-defined return type, so the exposure is hand-written and future declarations. Either substituting the parameters or rejecting a Type.UserDefined that still carries a ParameterStringValue would restore the documented behaviour.