>>>>> "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 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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
