semantics of "convenient to store" in FmgrInfo ?

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