From: Tom Lane <tgl@sss.pgh.pa.us>
To: John Lumby <johnlumby@hotmail.com>
cc: "pgsql-docs@lists.postgresql.org" <pgsql-docs@lists.postgresql.org>
Subject: Re: Set-Returning functions in a select list
In-reply-to: 
 <DM5PR06MB3082924AB2D1A3135D23F9C1A3E99@DM5PR06MB3082.namprd06.prod.outlook.com>
References: 
 <DM5PR06MB3082924AB2D1A3135D23F9C1A3E99@DM5PR06MB3082.namprd06.prod.outlook.com>
Comments: In-reply-to John Lumby <johnlumby@hotmail.com>
	message dated "Tue, 27 Jul 2021 16:19:42 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <351777.1627406643.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 27 Jul 2021 13:24:03 -0400
Message-ID: <351778.1627406643@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/351778.1627406643%40sss.pgh.pa.us>
Precedence: bulk

John Lumby <johnlumby@hotmail.com> writes:
> I feel that more on this topic needs to be added to the reference inform=
ation for SELECT,
> both in the description of the (expressions in the) SELECT-list and in t=
he 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 placi=
ng one or more what set-returning functions in the SELECT-list.      Also =
there should be a reference to the chapters under  "Query Language (SQL) F=
unctions" ,   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