>>>>> "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? What matters is whether get_expr_result_type still works; the only place (other than ruleutils) now that looks at funccoltypes etc. is the guts of that. Is it incorrect to assume that if a FuncExpr is transformed in any way, the result should give the same return from 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
