Skip site navigation (1) Skip section navigation (2)

Re: BUG #4434: Error inserting into view - unrecognized node type: 313

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Dean Rasheed <dean_rasheed(at)hotmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4434: Error inserting into view - unrecognized node type: 313
Date: 2008-09-24 14:20:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

pgsql-bugs by date

Next:From: Mathieu FenniakDate: 2008-09-24 16:00:52
Subject: BUG #4436: (E'\\' LIKE E'\\') => f
Previous:From: Chris BarnesDate: 2008-09-24 14:08:01
Subject: Postgres won't start and doesn't generate any messages.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group