undefined | Better HN

0 pointssbuttgereit7y ago0 comments

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.

0 comments

kierenj7y ago

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?

sbuttgereitOP7y ago

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.

j / k navigate · click thread line to collapse