On Mon, 13 May 2024 at 10:42, Artur Formella <artur.formel...@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. > Accepted: > SELECT 1,; > SELECT 1,,,,,; > SELECT *, from information_schema.sql_features; > (...) RETURNING a,,b,c,; > > Not accepted: > SELECT ,; > SELECT ,1; > SELECT ,,,; > > Advantages: > - simplifies the creation and debugging of queries by reducing the most > common syntax error, > - eliminates the need to use the popular `1::int as dummy` at the end of > a SELECT list, This is the first time I've heard of this `1 as dummy`. > - 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? > Disadvantages: > - counting of returned columns can be difficult, > - syntax checkers will still report errors, > - probably not SQL standard compliant, 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). > What do you think? 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. Kind regards, Matthias van de Meent Neon (https://neon.tech)
