I just use an array and implode it into a string. Then can both add and remove things.
How about trailing commas in SQL?
261–270 of 272 posts
Re: How about trailing commas in SQL?
#262Earlier quoted context omitted.
The closing tags should be optional too. [{},{},,,,{},, Should be fine. Now you can push things to the eof.
You probably want jsonlines. Being able to open a file in append mode without needing to parse the whole thing is great. https://jsonlines.org/
I get why one wants strict parsing rules but i don't see the point of closing tags. It seems nice enough to have [say] logs in json. Why would one need to add closing tags before consuming the json elsewhere? Parsing the entire thing is a huge waste of time if it is large.
I can use csv or html ofc.
Re: How about trailing commas in SQL?
#263Earlier quoted context omitted.
I mean, yes, technically, but is anyone's code actually breaking because of this? Who is writing SQL queries expecting them to fail because of this reason? By your definition, "backwards compatible" doesn't mean anything. Literally everything will be a breaking change if you define "backwards compatible" like this.
I think the term you are looking for is "forwards compatible"! Old SQL queries will still run fine on engines that support the new syntax (they're forwards compatible.) New SQL queries with trailing commas will NOT run fine on engines that don't support trailing commas; this is not a backwards-compatible change. And that's fine.
I think the question is whether you are disagreeing for pedantic reasons or are actually trying to contribute.
If you are trying to contribute, you will use the phrase backward compatible as we always do: my old code will still run after the change.
If you are trying to be pedantic, you will choose a new way of looking at it: My new code will not work if you go backward in time.
I don't care. I will swear to never write a dangling comma for any engine that doesn't support it. Also, I will swear to never use an engine that doesn't support it if once that does exists... Just as I did with Javascript.
Re: How about trailing commas in SQL?
#264> We support most cases, except the ones that are too complicated to implement or cause grammar conflicts. It would be really helpful if the author had provided at least a couple of these. I can't think of any obvious examples that would be complicated/conflicting, so it's not even clear if this is real complexity or not. I mean, it might be, but let's at least demonstrate that concretely? SQL grammar is pretty limit…
Yeah, this seems like the best option. I don't get the author's confusion
> Option 2 is weird, how do you determine the cutoff?
The cutoff seems obvious. If it is currently always a syntax error allow a comma, if it can be valid syntax preserve the existing behaviour.
I also can't think of any other cases right now, but if needed there can be a few places that don't allow trailing commas. As long as SELECT and CREATE TABLE support it 99% of the benefit will be there.
Re: How about trailing commas in SQL?
#265Earlier quoted context omitted.
Any new style will look bad, simply because it is new to us. But you quickly get used to it. After that, it is about minimizing errors. Leading commas minimize errors, and is a style that is portable across databases.
> Any new style will look bad, simply because it is new to us. I agree that new styles and syntaxes can take some getting used to. When I went from Pascal to C, braces seemed awful but I now think punctuation is much clearer than words for delimiting blocks. But the discussion here is about whether to introduce a new clearer style. Taken on this context, your comment amounts to defending any existing syntax, no matte…
> But the discussion here is about whether to introduce a new clearer style. Taken on this context, your comment amounts to defending any existing syntax, no matter how horrific, because you'll get used to it eventually.
No, I'm not defending any existing syntax.
As I said, it is about minimizing errors. You can get used to anything. But some styles and syntaxes are more error-prone than others. Leading commas in SQL is less error-prone, and therefore is preferred. No matter what your initial aesthetic impression. Allowing extra trailing commas is not portable, and therefore will increase errors if you come to rely on it then move between databases. So if the feature is provided, I will still be slow to adopt it into my style.
Re: How about trailing commas in SQL?
#266Earlier quoted context omitted.
JSON5 allows comments, it's been around since 2012. That said, JSON is not meant for humans / manual editing, and deciding to use it for configuration files was a mistake.
even if it wasn't meant for humans and manual editing, it works reasonably well for these usecases
I'd say it even works better than many common configuration filetypes such as YAML or INI.
Re: How about trailing commas in SQL?
#267Without talking about SQL it would be nice for git diff. I only see benefits of supporting them, hopefully this can be integrated into the SQL standards
And git blame, and it would reduce merge conflicts.
Please add this.
Re: How about trailing commas in SQL?
#268Earlier quoted context omitted.
Most SQL implementations do seem to allow you to name a column or a table with a keyword, but to refer to it you may need to put it in quotes or backticks. I'm not sure if this is a solved problem at the level of the ANSI SQL spec or if every vendor does their own thing, but there's definitely plenty of precedent that ambiguous grammar is allowed and can be resolved.
I know that MySQL uses backticks, Postgres/Sqlite uses double quotes, and MS SQL Server uses square brackets, when using keywords for a column or table.
The SQL standard uses double quotes.
Re: How about trailing commas in SQL?
#269Earlier quoted context omitted.
Because there's existing implementations that would interpret that as aliasing column names. ``` SELECT Field AS Renamed, OtherField AS AlsoRenamed ``` and ``` SELECT Field Renamed, OtherField AlsoRenamed ``` are semantically equivalent.
Making AS mandatory for naming columns would be an improvement in and of itself.
Yes, but it's also a breaking change to a very large legacy codebase. I can't see it ever happening, sadly.
Re: How about trailing commas in SQL?
#270Earlier quoted context omitted.
Since we're already here, we could think about trailing AND, actually. Look: SELECT a, sum(b), WHERE foo = 1 AND GROUP BY a Sounds pretty SQL to me.
This is cursed, but also entirely consistent with the trailing comma proposal. It'd sure look funny if all keywords that connected clauses together were trailable, though. SELECT a, sum(b), FROM stuff WHERE foo = 1 OR GROUP BY a Or just as horrifying: SELECT a, b, c, FROM foo UNION ALL SELECT a, b, c, FROM bar UNION ALL
Those aren't horrifying to me, only problem is that I want the keywords to right-align with each other.