I nominate this post for worst idea of the century.
How about trailing commas in SQL?
171–180 of 272 posts
Re: How about trailing commas in SQL?
#172I feel like this ship has sailed. SQL has been around for more than 50 years and everyone who needs to generate it has already put that extra `if` statement in to suppress trailing commas. What annoys me far more often is the lack of support for trailing commas in JSON.
Douglas Crockford made a commitment that JSON would never, ever get better. He promised us that it would always suck. He is as good as his word.
It has the small benefit that you never, ever have to worry about running into an old version of a JSON parser that bounces your fancy trailing commas.
Worth it? Not to me but Douglas Crockford does not care what I think. Or you either, apparently.
Re: How about trailing commas in SQL?
#173Earlier quoted context omitted.
The limitation is clearly not Rust. Any language that can bind to C libraries can bind to the functions PRQL exposes... the authors just haven't chosen to implement convenient SDKs for many languages. They also list 8 languages, not 4, just that they've had time to polish the libraries for 4 languages, apparently. PRQL appears to be a rather small project... not some major corporate effort.
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 from a C program, or from any other programming language that can bind to C.
Writing a header file manually is boring and error-prone, so people will often autogenerate the header file for the exposed functions using a tool like cbindgen: https://github.com/mozilla/cbindgen
We can see that PRQL is using cbindgen here to automatically create a C header: https://github.com/PRQL/prql/tree/main/prqlc/bindings/prqlc-...
The public API that PRQL wants to expose is defined in Rust here: https://github.com/PRQL/prql/blob/main/prqlc/bindings/prqlc-...
The generated C header file is here: https://github.com/PRQL/prql/blob/main/prqlc/bindings/prqlc-...
And that C header file -- combined with the compiled library -- should be all that is needed.
I suspect that the PRQL maintainer is saying that they want to offer a more idiomatic binding for C. The raw API that is exposed may not be the most user-friendly API, especially since they don't seem to have much familiarity with what is considered "idiomatic" in C, so they haven't been ready to commit to that API being considered "stable" yet. Based on my own poking around in their existing bindings... that C binding appears to be the API that they are using internally in those other language bindings already. (I'm also not sure how else they would be creating most of those bindings, if they weren't using that C binding... apart from some special cases, like how there is a convenient alternative for exposing bindings to Python from Rust, for example.)
We can see in the dotnet bindings, for example: https://github.com/PRQL/prql/blob/main/prqlc/bindings/dotnet...
C# does not allow directly using a C header file, so it requires manually re-defining the same set of extern function signatures, but it appears to be the same.
I'm not an expert on PRQL by any means, and it's been a few years since I really used Rust, but I'm just piecing together what I can see here.
This article I found could also be helpful: https://www.greyblake.com/blog/exposing-rust-library-to-c/
Rust code normally does not adhere to a C-compatible ABI, but the purpose of these "extern" functions is to do exactly that when you're trying to expose code that can be called by standard conventions... since the industry has largely settled on C-style functions and structs, for better or worse, with all of the limitations that imposes.
Re: How about trailing commas in SQL?
#174I have to add to my huge amusement at the particulars of this thread and deep appreciation for your nerdiness. As you can see from my other post here, I consider this question to be no question at all. Obviously all SQL engines should change. Equally obviously, they never will.
That all of you can take something so futile so seriously, spend time writing about your workarounds (which, of course, we all have in spades), is simply charming.
Thanks for you being you.
Re: How about trailing commas in SQL?
#175I really like the trailing comma, where it's supported, for that it can drive the language formatter - e.g. with trailing comma typically each item on it's own line, otherwise not. I think Dart is doing this, and other languages.
Re: How about trailing commas in SQL?
#176Please god. I don't believe in you but maybe someone else does and will think me a kindred spirit worthy of mercy. Let me have trailing commas. There is no reason not to. It's backward compatible, easy to implement and would make the world so so so much better.
they are _not_ backwards compatible. That's a big part of the problem. A trailing comma is a syntax error for an SQL engine without support for it
Re: How about trailing commas in SQL?
#177Earlier 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…
> FWIW, personally, I'd rather go the full-Python, using newlines as delimiters:
I love Python - mostly, but significant whitespace is its worst curse, and I'd love new languages to move away from the idea. I enjoy Rust because I can write out garbage faster than I can think of it, and the auto-formatter will make it look neat.
Also, have you experienced the unspeakable horror that is templating YAML files? Of course in SQL prepared statements is the safe&sane way to go, but there are cases where you still have to generate SQL as text, such as when building an ORM.
Re: How about trailing commas in SQL?
#178Should probably write a compiler that compiles "enhanced SQL" down to compatible SQL. Make it accept trailing commas, queries starting with FROM etc.
Re: How about trailing commas in SQL?
#179I feel the problem. When coding (not only in SQL) you often have to add something to the end of a list, and it is annoying that the end of the list is always special. You can't just copy some line and move it there. Also when moving things around you always have to take extra care at the end. So, my solution for this was always SELECT a , b , c FROM ... instead of: SELECT a, b, c, -- people want to allow trailing com…
This is how SQL Management Studio writes the queries it writes for you (like Select 1000 records) so when you comment out a line or lines, it doesn't cause any issues due to a misplaced comma.
Re: How about trailing commas in SQL?
#180I feel the problem. When coding (not only in SQL) you often have to add something to the end of a list, and it is annoying that the end of the list is always special. You can't just copy some line and move it there. Also when moving things around you always have to take extra care at the end. So, my solution for this was always SELECT a , b , c FROM ... instead of: SELECT a, b, c, -- people want to allow trailing com…
Another trick is, if you're programmatically building a SQL statement - adding "WHERE 1=1" makes things easier ... like so: SELECT * FROM table WHERE 1=1 That way, if you want to filter down the result, everything programmatically appended just needs an "AND ..." at the start, like: SELECT * FROM table WHERE 1=1 AND age > 21 AND xyz = 'abc' ... Because without "WHERE 1=1", you'd had to handle the first condition diff…
You can also just do "where true", easier to type.