Thread: DOC not so clear

DOC not so clear

From
PG Doc comments form
Date:
The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/11/queries-table-expressions.html
Description:

Hi.

https://www.postgresql.org/docs/current/queries-table-expressions.html#QUERIES-LATERAL
>The resulting row(s) are joined as usual with the rows they were computed
from.

Here is not so clear what 'joined as usual' mean.

Probably DOC should explicitly say that if LATERAL function return empty set
then current row is excluded from result set

Please clarify doc a bit.

Re: DOC not so clear

From
Tom Lane
Date:
=?utf-8?q?PG_Doc_comments_form?= <noreply@postgresql.org> writes:
> https://www.postgresql.org/docs/current/queries-table-expressions.html#QUERIES-LATERAL

>> The resulting row(s) are joined as usual with the rows they were computed
>> from.

> Here is not so clear what 'joined as usual' mean.

Why not?


> Probably DOC should explicitly say that if LATERAL function return empty set
> then current row is excluded from result set

That would be wrong for "LEFT JOIN LATERAL ...", so it does not seem
like an improvement.

            regards, tom lane


Re: DOC not so clear

From
Eugen Konkov
Date:
Hello Tom,

Monday, January 14, 2019, 6:15:31 PM, you wrote:

> =?utf-8?q?PG_Doc_comments_form?= <noreply@postgresql.org> writes:
>> https://www.postgresql.org/docs/current/queries-table-expressions.html#QUERIES-LATERAL

>>> The resulting row(s) are joined as usual with the rows they were computed
>>> from.

>> Here is not so clear what 'joined as usual' mean.

> Why not?

Advanced users may understand that, but from my beginner point of view
this  is  not. I do not understand that sentence until read whole text
and   about   LEFT   JOIN   LATERAL.   Even   now  'usual'  may  mean:
CROSS/RIGHT/FULL??


>> Probably DOC should explicitly say that if LATERAL function return empty set
>> then current row is excluded from result set

> That would be wrong for "LEFT JOIN LATERAL ...", so it does not seem
> like an improvement.

LATERAL != LEFT JOIN LATERAL
it would be more clear if DOC will be more explicit.


>                         regards, tom lane
-- 
Best regards,
Eugen Konkov



Re: DOC not so clear

From
"David G. Johnston"
Date:
On Monday, January 14, 2019, Eugen Konkov <kes-kes@yandex.ru> wrote:
Hello Tom,

Monday, January 14, 2019, 6:15:31 PM, you wrote:

> PG Doc comments form <noreply@postgresql.org> writes:
>> https://www.postgresql.org/docs/current/queries-table-expressions.html#QUERIES-LATERAL

>>> The resulting row(s) are joined as usual with the rows they were computed
>>> from.

>> Here is not so clear what 'joined as usual' mean.

> Why not?

Advanced users may understand that, but from my beginner point of view
this  is  not. I do not understand that sentence until read whole text
and   about   LEFT   JOIN   LATERAL.   Even   now  'usual'  may  mean:
CROSS/RIGHT/FULL?

“FROM from_item1, from_item2” has previously been defined to be a cross join - now with lateral specific from_item2 row(s) are generated using a single row of from_item1 and cross joined only to that row and no others.  Iteratively.

Left/right/full all require an on/using clause which is pointless for lateral as the injection of columns from the other row forms an explicit join link.
 

>> Probably DOC should explicitly say that if LATERAL function return empty set
>> then current row is excluded from result set

> That would be wrong for "LEFT JOIN LATERAL ...", so it does not seem
> like an improvement.

LATERAL != LEFT JOIN LATERAL
it would be more clear if DOC will be more explicit.


It does:
“It is often particularly handy to LEFT JOIN to a LATERAL subquery, so that source rows will appear in the result even if the LATERAL subquery produces no rows for them.”

There may be room for improvement here but it’s non-obvious what exactly it would look like.  It isn’t wrong nor particularly problematic given the lack of questions seen about lateral on these lists.  You are welcome to supply a patch for consideration though.

David J.