When do we get an object shell (powershell, there I said it) instead of old school strings?
Been using bash for over 20y, but MS had to make it popular.. I wouldn't mind at least a proof of concept for SQL
How about trailing commas in SQL?
101–110 of 272 posts
Re: How about trailing commas in SQL?
#102Earlier quoted context omitted.
If Rust can only be used with Rust, then it's strange that the project lists a number of other languages in the docs: https://prql-lang.org/book/project/bindings/index.html
Alright, it supports four languages, but that’s still not much.
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.
Re: How about trailing commas in SQL?
#103Let me start with FROM while we are at it.
Re: How about trailing commas in SQL?
#104I 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…
I've done this for arrays in JSON files, so that git merge will merge two changes that append to the list without a conflict.
I think the right answer is to fix the merge algorithm to handle some common cases where an inserted line logically includes the delimiter at the end of the previous line.
Re: How about trailing commas in SQL?
#105I 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…
I often do this with boolean WHERE filters when I'm doing interactive exploration on some data:
SELECT ...
WHERE
foo = 1
AND bar = 2
The solution is to start with "WHERE true":
SELECT ...
WHERE true
--AND foo = 1
AND bar = 2
(Putting the AND at end of each line has the same problem, of course, and requires putting a "true" at the bottom instead.)
Re: How about trailing commas in SQL?
#106I 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.
I feel the same way about SQL too, it's set and difficult to shift. But I also look at PRQL longingly - https://prql-lang.org/
Re: How about trailing commas in SQL?
#107I love it. I can see no downsides (as long as the updated implementations are well tested).
I reject any argument about how mature SQL is at this point. Just bump the version number (SQL 25) if necessary and make it so.
Re: How about trailing commas in SQL?
#108IIRC BigQuery started allowing trailing commas in queries around 2019. It all came as a very big surprise, out of thin air.
That's correct, and I absolutely love it. If I move to a new role where BigQuery is not the data warehouse of choice, I think this will be the thing I'll miss most.
Snowflake also allows trailing commas :)
Re: How about trailing commas in SQL?
#109I want leading _and_ trailing commas.
Frequently I will be working on a query and have something like
SELECT
a
, b
, c
from foo
Re: How about trailing commas in SQL?
#110Earlier quoted context omitted.
Alright, it supports four languages, but that’s still not much.
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.