Re: Document aggregate functions better w.r.t. ORDER BY - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Document aggregate functions better w.r.t. ORDER BY
Date
Msg-id CAKFQuwY90Z-Wbe98oDfWS2WLucPQ+e5vXsCHfTOdssXvTyU0Ng@mail.gmail.com
Whole thread Raw
In response to Re: Document aggregate functions better w.r.t. ORDER BY  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Document aggregate functions better w.r.t. ORDER BY
List pgsql-hackers
On Thu, Oct 26, 2023 at 2:56 PM Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Oct 25, 2023 at 10:34:10PM -0700, David G. Johnston wrote:
> I would reword the existing note to be something like:
>
> The SQL Standard defines specific aggregates and their properties, including
> which of DISTINCT and/or ORDER BY is allowed.  Due to the extensible nature of
> PostgreSQL it accepts either or both clauses for any aggregate.

Uh, is this something in my patch or somewhere else?  I don't think
PostgreSQL extensible is an example of syntax flexibility.


Note
The ability to specify both DISTINCT and ORDER BY in an aggregate function is a PostgreSQL extension.

I am pointing out that the first sentence of the existing note above seems to be factually incorrect.  I tried to make it correct - while explaining why we differ.  Though in truth I'd probably rather just remove the note.

> We get enough complaints regarding "apparent ordering" that I would like to
> add:
>
> As a reminder, while some DISTINCT processing algorithms produce sorted output
> as a side-effect, only by specifying ORDER BY is the output order guaranteed.

Well, we need to create a new email thread for this and look at all the
areas is applies to since this is a much larger issue.


I was hoping to sneak this one in regardless of the bigger picture issues, since this specific combination is guaranteed to output ordered presently.

David J.

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: [PoC] pg_upgrade: allow to upgrade publisher node
Next
From: Bharath Rupireddy
Date:
Subject: Re: Improve WALRead() to suck data directly from WAL buffers when possible