Re: Allowing additional commas between columns, and at the end of the SELECT clause
От | Artur Formella |
---|---|
Тема | Re: Allowing additional commas between columns, and at the end of the SELECT clause |
Дата | |
Msg-id | 30227830-c7e0-4c92-82e1-432b17e12a8d@gmail.com обсуждение исходный текст |
Ответ на | Re: Allowing additional commas between columns, and at the end of the SELECT clause (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Список | 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).
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 don't know, I have a feeling that the queries are equivalent, but I don't know the mechanism.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?
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 по дате отправления: