>>>>> "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

 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:

Reply via email to