On Tue, Jan 7, 2014 at 1:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
I still think that would be a good thing to do, but I don't see a
problem. The way I imagine it would work is: if the alias used for
the update target also appears in the FROM clause, then we treat them
as the same thing (after checking that they refer to the same table in
both cases). Otherwise, we add the update target as an additional
from-list item.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company