Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Tom Lane wrote:
>> It looks like the parser's code path for multi-row VALUES is neglecting
>> to detect sublinks and set pstate->p_hasSubLinks. I'm too tired to look
>> closer tonight; anyone want to poke into it?
> I think the parser is OK, but the p_hasSubLinks is lost in the rewrite
> phase.
Yeah, clearly so after comparing parser and rewriter outputs.
> In ResolveNew, we set p_hasSubLinks whenever a Var with a SubLink
> is found. In case of Values RTE, however, there's no Vars, but plain
> SubLink nodes. This patch seems to fix it:
No, that's not really where the problem is. After tracing through it,
it seems that the fault is with rewriteRuleAction(). That pastes the
source query's rtable into the rule action's query, but neglects to
consider the possibility that this change is introducing sublinks.
There is code there that will notice sublinks added from the source
query's jointree (ie, sublinks that are in WHERE or JOIN/ON), but
we are missing out on sublinks in VALUES RTEs ... and FUNCTION RTEs
too I suppose, so this goes back a ways. (The code was correct when
originally written, but now that we have expressions in some types of
RTEs, it's not.)
Will fix.
regards, tom lane
