Andrew Gierth <and...@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
> Tom> I've been hacking on this patch all day yesterday. What I'm on
> Tom> about at the moment is reversing the decision to move range
> Tom> functions' funccoltypes etc into FuncExpr. That's a bad idea on
> Tom> the grounds of bloating FuncExpr, but the real problem with it
> Tom> is this: what happens if the planner decides to inline or
> Tom> const-simplify the function expression? You just lost a
> Tom> critical part of the RTE's infrastructure, that's what.
> Inlining should already check that the type doesn't change as a
> result; where exactly is the issue here?
The issue is that if you want to dig column type information out of
a function RTE, that won't necessarily work after preprocess_expression
has had its way with the contained expressions. That's needed at
the very least in create_functionscan_plan.
You might try to argue that flattening of an expression-returning-RECORD
is guaranteed to preserve whatever we know about the result type, but
that argument sounds mighty flimsy to me. There's nothing much
guaranteeing that the expression couldn't be folded to a Const, or
at least something that didn't have a FuncExpr at the top.
In any case, there is absolutely nothing that is desirable enough
about this representation that we should take any risks for it.
The historical approach is that the coldeflist data is securely attached
to the RangeTblEntry itself, and I think we should stick with that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
