Make INLINE_MAX_LENGTH configurable

[nene]

This should clearly be configurable.

But the current implementation is a bit lacking. It considers the length of the parenthesized expression in isolation, but it should also consider the current indentation, because the whole point of it is really to limit how long the lines can be. By taking the indentation into the picture, we can name the config option to something like maxLineLength which would be instantly understandable, v/s something like maxParenthesizedExpressionLength.

[ukupat]

We know that we have the same issue jdorn/sql-formatter#59.

I was thinking about keeping AND and OR on the same line when the line is smaller than maxLineLength. This could solve that issue. What do you think @nene?

[nene]

This is now configurable through the lineWidth option. Though for now this configuration has all the problems listed above.

[jonahx]

@nene

Quick question: I was trying to specify a global line length limit (similar to prettier's printWidth) and tried the lineWidth option, but it didn't work. Based on your comment that it "has all the problems listed above", I am assuming this is simply not supported... is this correct? Thanks!

[nene]

This option has been renamed to expressionWidth, but it's behavior is far from intuitive.

Perhaps you're interested in trying out a new SQL formatting tool that I've written, which does support the printWidth option as it's implemented as a Prettier plugin and uses the same layout algorithm as Prettier.

[jonahx]

Thanks for the reply.

Perhaps you're interested in trying out a new SQL formatting tool that I've written

In theory yes, but I have a couple of requirements that brought me to the cmdline tool here....

1. Need pg and tsql support
2. We have a lot of SQL that exists within template literals in JS files. So with the command-line version, I can use a VS Code (or vim, etc) plugins to highlight lines of code inside template literals, pre-process them (eg, to replace interpolated ${vars}), run through sql-formatter, post-process, then replace the original text with formatted text.

2 is working great, except that there is no way to tell sql-formatter to respect the projects overall prettier printWidth, which would be ideal. I am open to other solutions if you know of any.

[nene]

The only other feasible option that I know of is SQLFluff. But that one is really primarily a linter and not really that great of an option for completely reformatting SQL code. Though it does have a max_line_length option and it's auto-fixable.

I'm planning to add Postgres support, but that will take time as Postgres is kinda big amongst SQL dialects. Transact-SQL is likely even more work as there are actually many dialects under this label and I find the syntax diagrams in Microsoft docs to be among the more confusing ones. However, currently Postgres support is definitely the most requested feature, so there's hope.