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

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> I've been hacking on this patch all day yesterday.  What I'm onTom> about at the moment is reversing the decision
tomove rangeTom> functions' funccoltypes etc into FuncExpr.  That's a bad idea onTom> the grounds of bloating FuncExpr,
butthe real problem with itTom> is this: what happens if the planner decides to inline orTom> const-simplify the
functionexpression?  You just lost aTom> 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)