Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How about trailing commas in SQL?

peter.eisentraut.org

Post reply on HN
Print view View original

211–220 of 272 posts

Re: How about trailing commas in SQL?

#211

Post by neonsunset »

coder543 wrote: post #173
xigoi wrote: post #110

Earlier quoted context omitted.

I wouldn’t mind writing the C bindings myself, but the docs say that not even C is officially supported.

I suspect there is a communications breakdown happening here. I'll try to clarify what I was saying, since I think I did a poor job. In Rust, when you define a `#[no_mangle] pub unsafe extern "C"` function, and then compile as a shared object / dll, that function will be exposed in an ABI-compatible way the same as any C function would be. It's just a matter of defining the proper header file so that you can use it f…

I know this is a bit offtopic but a lot of people have worse experience with using (otherwise excellent) PInvoke in .NET than strictly necessary.

> C# does not allow directly using a C header file

https://github.com/dotnet/ClangSharp?tab=readme-ov-file#gene...

there are bespoke libraries which build on top of it like CsWin32 where you specify the methods/modules to import and get nice and, often, memory-safe types and members in C#.

I think it should be possible to enhance this even further like having '// pinvkgen: #include ' at the top of any particular C# file and getting what you need in a C-like way. There are some problems with this inline approach but it could work.

The main point is there are quite a few community packages which simplify authoring bindings (there are more, like https://github.com/Cysharp/csbindgen/ for Rust or https://github.com/royalapplications/beyondnet for Swift). It really shouldn't be a necessity to write bindings by hand for large dependencies as it's both error prone and a solved problem.

Re: How about trailing commas in SQL?

#212

Post by wruza »

trailingcoma wrote: post #192
wruza wrote: post #3

To this still empty thread: how about we just stop arguing and add these damn commas everywhere? How about having human- and devenv-oriented languages finally, after how many decades?

How about we just do nothing and people write syntactically-correct SQL instead of demanding everyone and everything else change? I'm sorry, is this really the most important impediment to software development right now? Some guy's beef with the SQL parser?

You really want us to focus on more important impediments (whatever that means)? Just be glad we only want commas and add them already. If that trivial why even argue.

Re: How about trailing commas in SQL?

#213

Post by jmilloy »

dhruvrajvanshi wrote: post #206
tibbar wrote: post #187

Earlier quoted context omitted.

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.

> 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. But they never ran fine on engines that didn't support trailing commas in the first place :/ What you're calling "forwards compatible" is what I call "backwards compatible". Frankly, I suspect most people expect "backwards compatible" stuff to work like this. Is this disti…

I think the confusion may be whether you're talking about the queries or the engine. I think this change to the engine/parser would be backwards compatible because old queries will still work on the new engine. A change to the queries in a codebase to include trailing commas would not be backwards compatible because it won't work on older parsers. It seems clear to me that the change discussed here is the engine, hence it should properly be characterized as "backwards compatible".

Re: How about trailing commas in SQL?

#214

Post by trailingcoma »

wruza wrote: post #212
trailingcoma wrote: post #192

Earlier quoted context omitted.

How about we just do nothing and people write syntactically-correct SQL instead of demanding everyone and everything else change? I'm sorry, is this really the most important impediment to software development right now? Some guy's beef with the SQL parser?

You really want us to focus on more important impediments (whatever that means)? Just be glad we only want commas and add them already. If that trivial why even argue.

I anxiously await your pull request.

Re: How about trailing commas in SQL?

#215

Post by jaredsohn »

I think the right answer is that people who care about these things should use a client that rewrites queries via an LLM and clearly show the changes it makes (not sure if this exists yet but I'm sure it will). This also would handle a few other problems I've run into such as having multiple WHERE clauses or doing a WHERE prior to a JOIN and it could also allow using plain English to describe what you want to query.

I've found LLMs do a really good job of writing/cleaning up SQL.

Re: How about trailing commas in SQL?

#218

Post by dagss »

johnnyballgame wrote: post #217

Trailing commas are stupid no matter what language they are in.

I have the complete opposite view, it is stupid to not have them.

Whenever I edit JSON and SQL there is a lot of fiddling with commas when rearranging lines or adding new lines to the end of the list. In other languages I use (Go and TypeScript) there is no such fiddling.

Re: How about trailing commas in SQL?

#219

Post by larrik »

spprashant wrote: post #190

Not worth the trouble. This is such a cosmetic change to appease a specific type of developer but the effort to implement that across all the DB engines of note would be monumental.

It's not just cosmetic, though, as now in order to add a new entry at the end you need to change two lines of code, which means your git blame is no longer accurate.

Re: How about trailing commas in SQL?

#220

Post by ars »

specialist wrote: post #166
yellowapple wrote: post #130

Earlier quoted context omitted.

I don't want to write commas at all. I want to write SELECT a b c FROM d Or even SELECT a b c FROM d Because now selected values are uniform and there's no superfluous punctuation to worry about.

This would work (w/ a context free grammar) if aliases required the 'AS' keyword. Ambigious: SELECT a aliasA b c aliasC FROM d aliasD e Unambigious: SELECT a as aliasA b c as aliasC FROM d as aliasD e Alternately, a schema-aware parser could determine if 'aliasA' was an alias or a column reference. FWIW, personally, I'd rather go the full-Python, using newlines as delimiters: SELECT a aliasA b c aliasC FROM d aliasD…

Actually it's still ambiguous, because you forgot about sub-expressions. How would you parse this:

   SELECT a as aliasA b select q from foo as aliasQ c as aliasC FROM d as aliasD e
Even if you can figure it out (and add a 3rd level of sub-expression before deciding if you can), it's completely unreadable. You need either commas or parenthesis.
Post reply on HN