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