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
|
Список | 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 по дате отправления: