Re: UNNEST with multiple args, and TABLE with multiple funcs - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: UNNEST with multiple args, and TABLE with multiple funcs
Date
Msg-id 87li0kz0t9.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: UNNEST with multiple args, and TABLE with multiple funcs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: UNNEST with multiple args, and TABLE with multiple funcs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> I've been hacking on this patch all day yesterday.  What I'm onTom> about at the moment is reversing the decision
tomove rangeTom> functions' funccoltypes etc into FuncExpr.  That's a bad idea onTom> the grounds of bloating FuncExpr,
butthe real problem with itTom> is this: what happens if the planner decides to inline orTom> const-simplify the
functionexpression?  You just lost aTom> 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)



pgsql-hackers by date:

Previous
From: Gavin Flower
Date:
Subject: Re: additional json functionality
Next
From: Andrew Dunstan
Date:
Subject: Re: additional json functionality