I understand it as an attempt to get very basic, manual syntax highlighting. If all you have is white text on black background, then I do see the value of making keywords easy to spot by putting them in all caps. And this probably made sense back when SQL was first developed, but it’s 2023, any dev / data scientist not using a tool that gives you syntax highlighting seriously needs to get with the times
My ide isn’t limited to color when it comes to highlighting, so being color blind generally shouldn’t be a problem. Set keywords to underlined, bold, italic, whatever works for you.
Your other examples I can see, but at least at my work those are rare edge cases, and I’d rather optimize for the brunt of the work than for those. Of course at other places those might be much more of a concern.
As the other commenter said, the Jetbrains IDEs do this perfectly fine. Although I’d also argue that if you’re working with SQL from within another language already, a DSL wrapper is probably gonna be the better way to go about this.
Unfortunately RustRover is still garbage for actual usage. And I refuse to use an ORM when I can just write the SQL in a more common syntax that everyone understands across every language instead of whatever inefficient library-of-the-week there is. Raw SQL is fine and can be significantly more performant. Don’t be scared.
I’m not talking full blown ORM here, not a fan of those either. I’m talking about some light weight wrapper that basically just assembles SQL statements for you, while giving you just a little more type safety and automatic protection against SQL injection, and not sacrificing any performance. I’m coming from the JVM world, where Jooq and Exposed are examples of that kind of thing.
I’m currently using SQLx which you write raw queries in and it validates them against a currently-running db, using the description of the tables to build the typing for the return type instead of relying on the user. It makes it pretty hard to write anything that supports injection
Speaking as a Senior Dev specialized in database access and design… you don’t have to use all caps - SQL is actually case agnostic.
But… but my fucking eyes man. I’m old, if your branch doesn’t have control keywords in all caps I’m going to take it out back and ol’ yeller it.
There are few hills I’ll die on but all caps SQL and singular table names are two of them.
I’m a sql developer, and I am completely the opposite to you. I will find it incredibly difficult to read when everything is in caps
Same, I prefer lower case. Every other language has keywords in lower case, why do you need to shout when writing sql?
What about Intercal?
I understand it as an attempt to get very basic, manual syntax highlighting. If all you have is white text on black background, then I do see the value of making keywords easy to spot by putting them in all caps. And this probably made sense back when SQL was first developed, but it’s 2023, any dev / data scientist not using a tool that gives you syntax highlighting seriously needs to get with the times
Also some people are color blind.
Also you might need to ssh in somewhere and vi some code or tail a log file where you don’t have color support.
My ide isn’t limited to color when it comes to highlighting, so being color blind generally shouldn’t be a problem. Set keywords to underlined, bold, italic, whatever works for you.
Your other examples I can see, but at least at my work those are rare edge cases, and I’d rather optimize for the brunt of the work than for those. Of course at other places those might be much more of a concern.
Please tell me what IDE you’re using that’s capable of highlighting SQL syntax that’s embedded inside another language source file
Also please fucking stop with the “it’s current year stop x.” The year is not an argument.
As the other commenter said, the Jetbrains IDEs do this perfectly fine. Although I’d also argue that if you’re working with SQL from within another language already, a DSL wrapper is probably gonna be the better way to go about this.
Unfortunately RustRover is still garbage for actual usage. And I refuse to use an ORM when I can just write the SQL in a more common syntax that everyone understands across every language instead of whatever inefficient library-of-the-week there is. Raw SQL is fine and can be significantly more performant. Don’t be scared.
I’m not talking full blown ORM here, not a fan of those either. I’m talking about some light weight wrapper that basically just assembles SQL statements for you, while giving you just a little more type safety and automatic protection against SQL injection, and not sacrificing any performance. I’m coming from the JVM world, where Jooq and Exposed are examples of that kind of thing.
I’m currently using SQLx which you write raw queries in and it validates them against a currently-running db, using the description of the tables to build the typing for the return type instead of relying on the user. It makes it pretty hard to write anything that supports injection
You should do a project together
You monster.
The commit wars will be long and bloody.