Re: DOC not so clear

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: DOC not so clear
Дата
Msg-id CAKFQuwYQQwCxPTyndDYqKj+ZpRsnnHfJin+0dKmb2R7Eu-9nVg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: DOC not so clear  (Eugen Konkov <kes-kes@yandex.ru>)
Список pgsql-docs
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.

В списке pgsql-docs по дате отправления:

Предыдущее
От: Eugen Konkov
Дата:
Сообщение: Re: DOC not so clear
Следующее
От: PG Doc comments form
Дата:
Сообщение: Clarify behaviour of ADD COLUMN for partitioned tables