Re: Allowing additional commas between columns, and at the end of the SELECT clause - Mailing list pgsql-hackers

From Artur Formella
Subject Re: Allowing additional commas between columns, and at the end of the SELECT clause
Date
Msg-id 30227830-c7e0-4c92-82e1-432b17e12a8d@gmail.com
Whole thread Raw
In response to Re: Allowing additional commas between columns, and at the end of the SELECT clause  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
List pgsql-hackers
On 13.05.2024 11:24, Matthias van de Meent wrote:
On Mon, 13 May 2024 at 10:42, Artur Formella <artur.formella3@gmail.com> wrote:
Motivation:
Commas of this type are allowed in many programming languages, in some
it is even recommended to use them at the ends of lists or objects.
Single trailing commas are a feature that's more and more common in
languages, yes, but arbitrary excess commas is new to me. Could you
provide some examples of popular languages which have that, as I can't
think of any.
Thank for your comment.
I meant commas are recommended at the end of the list. Sorry for the lack of precision.
Typescript has a popular directive "rules": { "trailing-comma": false } in the tslint.json file, which forces trailing commas. Popular Airbnb coding style require trailing commas by eslint (https://github.com/airbnb/javascript?tab=readme-ov-file#functions--signature-invocation-indentation).

This is the first time I've heard of this `1 as dummy`.

dummy column is a popular way to end SELECT list on R&D phase to avoid the most common syntax error. This way you don't have to pay attention to commas.

SELECT <hacking /> , 1::int AS ignoreme FROM <hacking />

- simplifies query generators,
- the query is still deterministic,
What part of a query would (or would not) be deterministic? I don't
think I understand the potential concern here. Is it about whether the
statement can be parsed deterministically?

Bison doesn't report error or conflict.

I'd argue you better raise this with the standard committee if this
isn't compliant. I don't see enough added value to break standard
compliance here, especially when the standard may at some point allow
only a single trailing comma (and not arbitrarily many).


Do you expect `SELECT 1,,,,,,,` to have an equivalent query identifier
to `SELECT 1;` in pg_stat_statements? Why, or why not?
I don't know, I have a feeling that the queries are equivalent, but I don't know the mechanism.
Overall, I don't think unlimited commas is a good feature. A trailing
comma in the select list would be less problematic, but I'd still want
to follow the standard first and foremost.

I will prepare a patch with trailing comma only tomorrow.

Thank you.

Artur


pgsql-hackers by date:

Previous
From: Fabrízio de Royes Mello
Date:
Subject: Re: Adding the extension name to EData / log_line_prefix
Next
From: Jacob Champion
Date:
Subject: Re: Direct SSL connection with ALPN and HBA rules