Tangentially related. I'm of the opinion that SQL shouldn't be uppercased. I don't want to hit shift or caps lock and I find lowercase easier to read.<p>Are there others out there like me? I assume I'm in the minority, but I don't understand why. People stopped uppercasing HTML tags, why can't we do the same with SQL?
Author here. Based on feedback I am going to make a sqlfmt binary for easy editor integration.<p>You can currently already do this by using the CockroachDB binary (<a href="https://www.cockroachlabs.com/docs/releases/v2.1.0-beta.20180924.html" rel="nofollow">https://www.cockroachlabs.com/docs/releases/v2.1.0-beta.2018...</a>) but understandably people want a more minimal solution.
If you're working with something close to PostgreSQL syntax support, why wouldn't you start with pgFormatter (<a href="http://sqlformat.darold.net/" rel="nofollow">http://sqlformat.darold.net/</a>)? It's been around for awhile and I can't see anything new or substantially more advanced in the proposed solution.<p>I have to say, I do most of my development work in the database, and I'm not thrilled with any of the automatic formatters thus far. The ones I've seen can do a good job in many cases, but if you start getting very advanced at all, the weaknesses of an automatic formatting approach start to become more evident. It may just be that anything other than relatively simple SQL, PL/SQL are not well suited for automatic formatting.<p>I'm still working through a good set of formatting rules, and I always find I end up making exceptions for readability.
Brief question, only tangentially related:<p>Is it me or is "opinionated" software popping up all over the place? It looks to me like the author considers it a selling point, too.<p>Can someone explain to me why I would want an "opinionated" software over any regular old software? Especially over a configurable software?<p>I'm not a native speaker, but I never encountered "opinionated" being used with positive connotation. It has so far always been in the "well, uh, he's very opinionated!" sense of apologizing for that old grumpy person who gets on everybody's nerves.
Great idea.<p>I work on a project that's grown in complexity and team size. Developers have come and gone. Sometimes a bit of code that's grown over a few years needs its style to evolve. This kind of formatter clearly realizes this.<p>What I tell developers that complain about this or that style is that it's more important to have a consistent code style throughout the lifetime of a project, then to adopt whatever bracing style someone happens to like at the time.<p>I'd really like all of my code to be automatically formatted with a tool like this, as part of the build process. This would help with situations where code evolves, as it would reformat it when needed.
The problem with opinions is everyone has a different one.<p>I like <a href="https://www.sqlinform.com/" rel="nofollow">https://www.sqlinform.com/</a> - keep a copy of notepad around just so I can use it. Wish there was a VSCode extension. The free version was good enough for my needs, but it's so handy I upgraded to the pro version just to show appreciation. The best part is the ability to really customize the layout and save the settings. It's always step #1 when someone sends me a massive blob of badly formatted SQL.
This looks great! I notice you mentioned Prettier in the post — do you have any plans to integrate sqlfmt with that?<p>Prettier actually has a beta Postgres plugin, but progress on it seems to have stalled. Hooking it up with sqlfmt would be neat - then prettier could format SQL inside other languages too, like code fences in Markdown or template literals in JS.
Looks really cool, but I have one suggestion. Have you considered using leading commas? It makes big SQL statements much easier to edit and it improves diffs. I normally use trailing commas for my code, but most sql dialects don't support it so I fallback to leading ones there.
I was just wishing for a better SQL formatter! I'm wasting too much time pasting queries into a doc just to reformat them.<p>It would be great if the parser supported question marks as placeholders. The pg_stat_statements table in Postgres saves denormalized queries, replacing the literal values with '?' placeholders (e.g., `SELECT * FROM table_name WHERE id = ?`).
What I want: an SQL (actually, it could be just Postgres as I only use that) parser that takes two schema declarations and calculates the commands needed to go from one to the other, so we can have automatic migrations.<p>For example, if A is<p><pre><code> CREATE TABLE person (
id serial PRIMARY KEY,
name text
)
</code></pre>
and B is<p><pre><code> CREATE TABLE person (
id serial PRIMARY KEY,
name text,
age int
)
</code></pre>
Then this tool would output<p><pre><code> ALTER TABLE person ADD COLUMN age int</code></pre>
I’d love it if StackOverflow would let me select code text and automatically reformat it according to some standard spec (I don’t care which set of opinions are used provided it’s readable!) - too many inexperienced (or unqualified, it seems) people copy and paste ad-hoc written SQL that I always have to manually reformat myself when I edit their questions for readability.
I would love to package this (most likely from <a href="https://github.com/lopezator/sqlfmt" rel="nofollow">https://github.com/lopezator/sqlfmt</a>) for my package manager of choice. What is the license?
that would be really cool to have as a local package you can plug into your text editor instead of copy and paste. people using this at companies might leak sensitive information or possible attack vectors to the opaque service.
I would challenge the decision to UPPER CASE keywords, it looks oldschool and is unnecessary since syntax highlighting is ubiquitous. And right-justifying is something that only looks clean for the simplest of queries and wreaks havoc with editors that detect mixed tabs/spaces.
not sure what this offers over<p><a href="https://sqlformat.org/" rel="nofollow">https://sqlformat.org/</a><p>or<p><a href="http://www.dpriver.com/pp/sqlformat.htm" rel="nofollow">http://www.dpriver.com/pp/sqlformat.htm</a><p>both of which seem to give nicer output and handle more diverse sql without erroring.<p>also not really sure why it considers itself "opinionated"
Why all the SCREAMING? Is something wrong?<p>It's 2018, we aren't using teletypes with bad shift keys and we all have syntax coloring IDEs, we don't need to scream out all our KEYWORDS like we were still writing COBOL or FORTRAN in the 1960s.<p>It's become my biggest pet peeve with most SQL formatters. I think sentence cased SQL is far more readable.<p><pre><code> Select * from sometable where SomeColumn > 3
</code></pre>
But I realize I'm a minority with the opinion right now.
"As my code gets more complicated or deeplier nested"<p>OMG will someone please tell college professors about Clean Code? Perhaps it takes years of writing deeplier nested code before you even know what Uncle Bob is talking about.