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

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 out
Tom> of a function RTE, that won't necessarily work after
Tom> preprocess_expression has had its way with the contained
Tom> expressions. That's needed at the very least in
Tom> 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 an
Tom> expression-returning-RECORD is guaranteed to preserve whatever
Tom> we know about the result type, but that argument sounds mighty
Tom> flimsy to me. There's nothing much guaranteeing that the
Tom> expression couldn't be folded to a Const, or at least something
Tom> that didn't have a FuncExpr at 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 desirable
Tom> enough about this representation that we should take any risks
Tom> for it. The historical approach is that the coldeflist data is
Tom> securely attached to the RangeTblEntry itself, and I think we
Tom> 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)