amshank

Most of the SQLFluff style was based around the Mozilla SQL style guide and the dbt labs style guide: https://docs.telemetry.mozilla.org/concepts/sql_style.html https://github.com/dbt-labs/corp/blob/master/dbt_style_guide...

The GitLab SQL style guide isn't far off either: https://about.gitlab.com/handbook/business-technology/data-t...

Rather than supporting _all_ ways of formatting SQL, the aim of the tool was to fairly flexibly support the most mainstream ones with a view to becoming more opinionated in future to converge on a more unified style in future. Similar to what black has done with python.

It's pretty new functionality in sqlfluff, but it now supports user defined plugins for org-specific rules if you want to forbid something more obscure. Documentation is sketchy, but you can see the proof of concept here: https://github.com/sqlfluff/sqlfluff/tree/main/plugins/sqlfl...

The reason that those people care about formatting is that it matters when the code is used to communicate with other people, not just with machines. Having a consistent style within the team, means the team can communicate more easily - even if the net effect for an individual working on a codebase alone is minimal.

You're totally right that there isn't any consistency in this space at the moment. It's part of the justification for tools like SQLFluff starting to align people on a common way of writing SQL. None of the incumbent players have an incentive to do that.

Auto-formatter is already built in for some simple violations: https://docs.sqlfluff.com/en/stable/cli.html#sqlfluff-fix