Re: Failed assertion root->hasLateralRTEs on initsplan.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Failed assertion root->hasLateralRTEs on initsplan.c
Date
Msg-id 17284.1389118549@sss.pgh.pa.us
Whole thread Raw
In response to Failed assertion root->hasLateralRTEs on initsplan.c  (Emre Hasegeli <emre@hasegeli.com>)
Responses Re: Failed assertion root->hasLateralRTEs on initsplan.c  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Emre Hasegeli <emre@hasegeli.com> writes:
> I get assertion failure on initsplan.c line 1325 while executing following query
> on HEAD (edc43458d797a5956f4bf39af18cf62abb0077db). It works fine
> without --enable-cassert.

> update subscriber set properties = hstore(a) from (select firstname,
> lastname from player where player.id = subscriber.id) as a;

Hm, AFAICS this query should absolutely *not* work; the reference to
subscriber.id inside the sub-select is illegal.  It might be legal with
LATERAL, but not otherwise.  So I think this is a parser bug, and there's
nothing wrong with the planner's Assert.  9.2 and earlier throw the
error I'd expect, so probably something in the LATERAL patches broke
this case; will look.

The next question is if we should allow it with LATERAL.  That would
essentially be treating "subscriber" as having implicitly appeared at the
start of the FROM list, which I guess is all right ... but does anyone
want to argue against it?  I seem to recall some old discussions about
allowing the update target to be explicitly shown in FROM, in case you
wanted say to left join it against something else.  Allowing this implicit
appearance might limit our options if we ever get around to trying to do
that.  On the other hand, those discussions were a long time back, so
maybe it'll never happen anyway.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Fixing pg_basebackup with tablespaces found in $PGDATA
Next
From: Kevin Grittner
Date:
Subject: Re: Re: How to reproduce serialization failure for a read only transaction.