[sbuttgereit]

If you're working with something close to PostgreSQL syntax support, why wouldn't you start with pgFormatter (http://sqlformat.darold.net/)? It's been around for awhile and I can't see anything new or substantially more advanced in the proposed solution.

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.

I'm still working through a good set of formatting rules, and I always find I end up making exceptions for readability.

[coder543]

pgFormatter formats

  SELECT 1, 2

as

  SELECT
      1,
      2

which is one of the core complaints the article addresses.

[sbuttgereit]

That actually seems like a relatively minor complaint on the order of submitting a pull request to an existing fairly good project (as is pgFormatter) rather than coming up with standard 15 for SQL formatting in a new tool. An option where, if the column text doesn't overrun a column limit, is single line and then split once it does overrun doesn't sound like a bad feature, but it does sound like a small one.

(addition) More than anything that's wrong with all of these formatters for SQL is that there real consensus for what good formatting is. There are historical norms for sure, and that's likely a starting point, but reconciliation between the communities around each database vendor (and sometimes each company developing with that database) make that a difficult challenge. So this new tool will become the CockroachDB formatter, pgFormatter is as far as I know the most popular PostgreSQL formatter, other databases your mileage will vary. Each not really an SQL formatter, but an SQL formatter for (stick affinity here). For CockroachDB, I'm not sure how much payoff there is for moving away from the more popular tool for Postgres if they're stressing their similarity to PostgreSQL SQL.

[kierenj]

It sounds like this formatter is sufficiently different in its approach (based on the prettier paper) that a PR would basically rewrite the existing one?

[sbuttgereit]

My point is why create something new on any basis, if there's a fairly good solution to the problem that you can help improve?

Sure, once you've gone and created a brand new tool you've gone past the point of a PR unless you were starting with a fork. My original question was, why jump to a new tool out of the gate when the differences seem fairly minor. Yes, I'm sure that pgFormatter probably didn't start with the prettier paper... but so what? If you aren't coming up with something really different, I'm not sure that matters.

Actually, thinking about it. What I need more than an SQL formatter is something closer to a linter quite frankly. In complex queries it's easy to miss something... I know, I know... I'm probably talking about something more like an IDE since many of the errors are likely to be logical rather than syntactic, but still... that would be a better problem to solve than a formatter right now.