Set-Returning functions in a select list
re the recent discussion ending with this thread
/messages/by-id/1163940.1627142622@sss.pgh.pa.us
in pgsql-general
I feel that more on this topic needs to be added to the reference information for SELECT,
both in the description of the (expressions in the) SELECT-list and in the description of the FROM list, and in particular a note on how and why certain usages are equivalent when written in specific ways, (and maybe even which is preferred).
Currently there is a thorough description of the semantics of [ LATERAL ] ROWS FROM in the FROM list, but very little about the effect of placing one or more what set-returning functions in the SELECT-list. Also there should be a reference to the chapters under "Query Language (SQL) Functions" , especially sub-chapter "SQL Functions Returning Sets"
Cheers, John
John Lumby <johnlumby@hotmail.com> writes:
I feel that more on this topic needs to be added to the reference information for SELECT,
both in the description of the (expressions in the) SELECT-list and in the description of the FROM list, and in particular a note on how and why certain usages are equivalent when written in specific ways, (and maybe even which is preferred).
Currently there is a thorough description of the semantics of [ LATERAL ] ROWS FROM in the FROM list, but very little about the effect of placing one or more what set-returning functions in the SELECT-list. Also there should be a reference to the chapters under "Query Language (SQL) Functions" , especially sub-chapter "SQL Functions Returning Sets"
The bigger picture here is that there's a lot of detail in 38.5 that
is of interest to users of built-in functions, not only to people
writing new functions. We've had discussions before about refactoring
that material so that some of it could be moved into a more prominent
place, probably in chapter 7 (Queries) or maybe chapter 9 (Functions
and Operators). Nobody's produced a coherent proposal though. In the
meantime I'm not much on board with sprinkling cross-references into
random places, if only because those references will be pointing to
the wrong place when/if this refactoring does happen.
regards, tom lane