Re: UNNEST with multiple args, and TABLE with multiple funcs

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

Tom> I've been hacking on this patch all day yesterday. What I'm on
Tom> about at the moment is reversing the decision to move range
Tom> functions' funccoltypes etc into FuncExpr. That's a bad idea on
Tom> the grounds of bloating FuncExpr, but the real problem with it
Tom> is this: what happens if the planner decides to inline or
Tom> const-simplify the function expression? You just lost a
Tom> critical part of the RTE's infrastructure, that's what.

Inlining should already check that the type doesn't change as a
result; where exactly is the issue here?

What matters is whether get_expr_result_type still works; the only
place (other than ruleutils) now that looks at funccoltypes etc. is
the guts of that. Is it incorrect to assume that if a FuncExpr is
transformed in any way, the result should give the same return from
get_expr_result_type?

--
Andrew (irc:RhodiumToad)