>>>>> "Tom" == Tom Lane <t...@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 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
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
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.
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: