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

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Inlining should already check that the type doesn't change as a>> result; where exactly is the issue here?
Tom> The issue is that if you want to dig column type information outTom> of a function RTE, that won't necessarily
workafterTom> preprocess_expression has had its way with the containedTom> expressions.  That's needed at the very
leastinTom> create_functionscan_plan.
 

My intention was that whatever was in the funcexprs list should be
self-describing as far as result type information goes - whether or
not it was a FuncExpr node.  create_functionscan_plan used to copy the
funccoltypes etc. to the FunctionScan node, but I removed that in
favour of having get_expr_result_type do the work.
Tom> You might try to argue that flattening of anTom> expression-returning-RECORD is guaranteed to preserve
whateverTom>we know about the result type, but that argument sounds mightyTom> flimsy to me.  There's nothing much
guaranteeingthat theTom> expression couldn't be folded to a Const, or at least somethingTom> that didn't have a
FuncExprat the top.
 

So, at the moment, get_expr_result_type can't return a tupdesc for an
expression tree that doesn't have FuncExpr or OpExpr at the top and
which doesn't return a named composite type.

If there's an issue here, then it goes beyond functions-returning-RECORD
and affects flattening of functions with OUT parameters too; if there
were some way for those to get replaced by a Const node (currently
there is not: see comment in evaluate_function) then that would break,
and that clearly has nothing to do with coldef lists.

I can see that it would be nice to allow folding and so on in these
cases, but it seems to me that having some infrastructure that would
allow get_expr_result_type to return the same result for the
transformed call as the original call is a prerequisite for any such
change.
Tom> In any case, there is absolutely nothing that is desirableTom> enough about this representation that we should
takeany risksTom> for it.  The historical approach is that the coldeflist data isTom> securely attached to the
RangeTblEntryitself, and I think weTom> should stick with that.
 

What I was aiming for was to _remove_ any special-case handling of
coldef lists (post-parser) and use only get_expr_result_type.

-- 
Andrew. (irc:RhodiumToad)