Date: Wed, 6 Sep 2023 19:51:34 -0400
From: Bruce Momjian <bruce@momjian.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, postgres-hape@gmx.de,
	pgsql-docs@lists.postgresql.org
Subject: Re: group by can use alias from select list
Message-ID: <ZPkQhuV8I6ijH+y3@momjian.us>
References: <168871536004.379168.9352636188330923805@wrigleys.postgresql.org>
 <25b70e6ec7bef81acac508dc61dfa01e72c96252.camel@cybertec.at>
 <CAKFQuwYALfM-yamV7GCPG_WZvi_qK5O8rJPOGkD40ShDd9M_GQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="pUmxj/d3rwaUVJ14"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAKFQuwYALfM-yamV7GCPG_WZvi_qK5O8rJPOGkD40ShDd9M_GQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ZPkQhuV8I6ijH%2By3%40momjian.us>
Precedence: bulk


--pUmxj/d3rwaUVJ14
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On Tue, Jul 11, 2023 at 07:31:26AM -0700, David G. Johnston wrote:
> On Tue, Jul 11, 2023 at 7:19 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> 
>     On Fri, 2023-07-07 at 07:36 +0000, PG Doc comments form wrote:
>     > i have a discussion in pgsql-bugs@lists.postgresql.org about this and it
>     is
>     > mentioned in the answers that it is documented and a "feature" of
>     Postgres
>     > that this can be done.
>     > If this is wanted the documentation
>     > (https://www.postgresql.org/docs/current/sql-select.html) that mentioned:
>     > [execution order of SELECT that says that GROUP BY is before SELECT]
>     > isn't correct because how  can 4.) be done and the alias from 5.) is
>     used?
>     > Here is a hint important that there is an exception for alias used in
>     group
>     > by
> 
>     I think that is already documented:
> 
> 
> 
> I think the complaint is that someone seeing the behavior in the wild comes to
> this order-of-operations and doesn't see that the observed behavior is
> documented.  Sure, they can go into the GROUP BY section and figure out that
> there is a "oh, by the way" comment within there that output columns/aliases
> are indeed allowed.  But I tend to agree that a mention in the "order of
> operations" section that output columns from step 5 can be seen in step 4 seems
> like an improvement if we really want the order of operations to be the main
> reference entry point for people trying to work out query behavior.  Something
> like:  "(while unadvised it is possible for the aliases defined in the next
> step to be used here as well)".

How is the attached patch?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

--pUmxj/d3rwaUVJ14
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="group-by.diff"

diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 0ee0cc7e64..9c354f7033 100644
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -130,7 +130,9 @@ TABLE [ ONLY ] <replaceable class="parameter">table_name</replaceable> [ * ]
       If the <literal>HAVING</literal> clause is present, it
       eliminates groups that do not satisfy the given condition.  (See
       <xref linkend="sql-groupby"/> and
-      <xref linkend="sql-having"/> below.)
+      <xref linkend="sql-having"/> below.)  Names and ordinal numbers of
+      output columns, computed in the next step, can also be referenced
+      by <literal>GROUP BY</literal>.
      </para>
     </listitem>
 

--pUmxj/d3rwaUVJ14--