From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | emre(at)hasegeli(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Failed assertion root->hasLateralRTEs on initsplan.c |
Date: | 2014-01-07 18:15:49 |
Message-ID: | 17284.1389118549@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Emre Hasegeli <emre(at)hasegeli(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2014-01-07 19:11:33 | Re: Re: How to reproduce serialization failure for a read only transaction. |
Previous Message | Dimitri Fontaine | 2014-01-07 17:26:28 | Re: Fixing pg_basebackup with tablespaces found in $PGDATA |