Re: LATERAL and VOLATILE functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: LATERAL and VOLATILE functions
Date: 2012-12-15 22:06:07
Message-ID: 29593.1355609167@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> Is this behave expected?

> -- unexpected
> postgres=# select * from generate_series(1,3) g(v), LATERAL (SELECT random()) x;
> ;
> v random
> ---+------------------
> 1 0.63025646051392
> 2 0.63025646051392
> 3 0.63025646051392
> (3 rows)

The LATERAL keyword is a no-op since x doesn't contain any
side-reference to g(v). So you get a plain join between g and
a single-row relation x.

If the SQL standard actually specified what LATERAL means, we could
argue about whether that's a correct interpretation or not. I haven't
been able to find anyplace where the spec defines the semantics though.

And I'm fairly certain that we *don't* want it to mean "recompute
for every row generated to the left of the keyword, whether there is
a variable reference or not". Consider for example

select ... from a, b, c join lateral d on ...

If the D item only contains references to C, it's unlikely that the
programmer wants it to be re-evaluated again for each possible row
in A*B.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2012-12-15 22:24:46 Re: LATERAL and VOLATILE functions
Previous Message Tom Lane 2012-12-15 21:48:08 Re: Set visibility map bit after HOT prune