SQL formatter that knows your dialect

No — the planner never sees your whitespace, because the parser has already thrown it away by the time an execution plan is built. There is one second-order effect worth knowing: SQL Server and Oracle key the plan cache on the literal text of an ad-hoc statement, so a reformatted query is a cache miss and gets compiled once more, landing beside the old entry rather than replacing it. The plan that comes out is the same plan; you have simply paid for one more compile and one more cache slot. Parameterised statements and prepared handles are unaffected.

Because only the 185 words this formatter recognises get recased, and everything else is assumed to be your identifier. That is deliberate: a column genuinely called status, order or key must not be shouted at, and MySQL and PostgreSQL each add reserved words the other does not have. Anything inside quotes is untouchable in any dialect — a string literal keeps its case because changing it would change the data the query matches, and "Order Id" or [Order Id] keeps its case because in PostgreSQL and SQL Server a quoted identifier is case-sensitive.

Start with standard, then switch if the output looks wrong around quotes. The tell for MySQL is a backtick, and MySQL is also the one dialect where "double quotes" hold a string rather than name a column — the others read that as an identifier, which is why picking the wrong one can turn a whole string into a column name in the output. The tell for T-SQL is [square brackets] or an @variable; the tell for PostgreSQL is $$, E'…' or a $1 placeholder. Only the reading changes, never the tokens.

No, because the reader tracks quotes before it looks for anything else. A literal such as 'a -- not a comment; really' is one token from the opening quote to the closing one, so neither the double dash nor the semicolon inside it can end a comment or split a statement. Doubled quotes are handled the way the standard defines them — 'it''s here' is a single value — and in MySQL and PostgreSQL a backslash escape is read as an escape rather than as the end of the literal.

After it, unless your team has already agreed otherwise, in which case the leading-comma switch is there. Leading commas exist for a practical reason rather than an aesthetic one: with the comma at the start of the line, commenting out the last column in a SELECT list does not leave a dangling comma behind, and adding a column produces a one-line diff instead of a two-line one. The cost is that the first item is the odd one out, and that most people find it harder to read at a glance.

The statement around it, yes; the body inside dollar quotes, deliberately not. A $$ … $$ block is a string literal as far as PostgreSQL is concerned, and its contents are a different language with its own control flow — re-indenting it would mean writing a second formatter and guessing about the first. So CREATE FUNCTION, its argument list and its LANGUAGE clause are laid out, and the body between the dollar quotes arrives exactly as you wrote it. In T-SQL, a BEGIN … END block does get indented, because there the statements inside it are ordinary SQL.

Every one is kept, and a comment that shared a line with code stays on that line. A double-dash comment ends the line it is on, so it is written out first and the code that followed it moves down; a /* block */ comment written mid-clause stays where it sits between the two tokens it separated. PostgreSQL is the only dialect here where block comments nest, and it is read that way, so an outer /* wrapped around code that already contains one does not end early and swallow half the query.