Hi, At one time 12 years ago, fn_collation was stored in FmgrInfo, with a comment saying it was really "parse-time-determined information about the arguments, rather than about the function itself" but saying "it's convenient" to store it in FmgrInfo rather than in FunctionCallInfoData.
But in d64713d, fn_collation was booted out of FmgrInfo and into FunctionCallInfoData, with this commit comment: "Since collation is effectively an argument, not a property of the function, FmgrInfo is really the wrong place for it; and this becomes critical in cases where a cached FmgrInfo is used for varying purposes that might need different collation settings." However, fn_expr is still there in FmgrInfo, with exactly the same vague rationale in the comment about being "convenient" to keep in FmgrInfo rather than in the function call info where it might more logically belong. Is there a good quick story for why that's ok for fn_expr and not for fn_collation? In particular, what can I count on? Can I count on, if a FmgrInfo has a non-null fn_expr, that all forthcoming function calls based on it will have: - the same value for fcinfo->nargs ? (matching the count of fn_expr) - the same arg types (and same polymorphic arg resolved types) ? Then what about fcinfo->fn_collation? Can it vary from one call to another in those circumstances? Or can that only happen when fn_expr is null, and a cached FmgrInfo is being used for varying purposes /other than/ "as part of an SQL expression"? Are there ever circumstances where a FmgrInfo with a non-null fn_expr is reused with a different fn_expr? Regards, -Chap
