Re: Failed assertion root->hasLateralRTEs on initsplan.c

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Failed assertion root->hasLateralRTEs on initsplan.c
Дата
Msg-id 17284.1389118549@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Failed assertion root->hasLateralRTEs on initsplan.c  (Emre Hasegeli <emre@hasegeli.com>)
Ответы Re: Failed assertion root->hasLateralRTEs on initsplan.c  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Fixing pg_basebackup with tablespaces found in $PGDATA
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: Re: How to reproduce serialization failure for a read only transaction.