Re: description of Aggregate Expressions

On 12/05/19 18:06, David G. Johnston wrote:
On Thu, Dec 5, 2019 at 3:18 PM John Lumby <<mailto:johnlumby(at)hotmail(dot)com>johnlumby(at)hotmail(dot)com<mailto:johnlumby(at)hotmail(dot)com>> wrote:
In PostgreSQL 12.1 Documentation chapter 4.2.7. Aggregate Expressions it says

The syntax of an aggregate expression is one of the following:
...
aggregate_name (DISTINCT expression [ , ... ] [ order_by_clause ] ) [ FILTER ( WHERE filter_clause ) ]
...

I believe this is incorrect in the case where the DISTINCT is on a comma-separated list of expressions.
It would imply that this is legal

It is...you didn't get a syntax error.

Hmm, even though true, I think this is unhelpful.
If a reference document states that the syntax for a something-or-other construct is one of the following diagrams,
then I expect that the diagrams are valid for *every* kind of something-or-other, not just some.
Yet the diagram I quote always results in being rejected in the case of COUNT -
which I consider to be as good as saying it is invalid syntax.

select count(DISTINCT parent_id , name) from mytable

but that is rejected with
ERROR: function count(bigint, text) does not exist

The error is that while the query is syntactically correct in order to execute it as written a function would need to exist that does not. As far as a general syntax diagram goes it has correctly communicated what is legal.

whereas

select count(DISTINCT ( parent_id , name) ) from mytable

is accepted.

Correct, converting the two individual columns into a "tuple" allows the default tuple distinct-making infrastructure to be used to execute the query.

So I think to handle all cases the line in the doc should read

aggregate_name (DISTINCT ( expression [ , ... ] ) [ order_by_clause ] ) [ FILTER ( WHERE filter_clause ) ]

I don't know how to indicate that those extra parentheses can be omitted if the list has only one expression.

Then I would have to say the proposed solution to this edge case is worse than the problem. I also don't expect there to be a clean solution to dealing with the complexities of expressions at the syntax diagram level.

Yes, I see what I suggested is not ideal either. But I think something needs to be changed.

How about replacing "expression [ , ... ]" by "parameter_list" in the description, and then stating that parameter_list can be either a single expression or , if the particular aggregate function accepts it (for which, consult that function's reference), a comma-separated list of expressions.

David J.