Hi Christopher, > I totally disagree. You don't need a sophisticated lexer to format Java, > XML, SQL and these kind of languages. I am not talking about PL-SQL or T-SQL > but normal SQL.
I'm just saying it's non-trivial to distinguish UPDATE .. SET from MERGE .. WHEN MATCHED THEN UPDATE SET and from INSERT .. ON DUPLICATE KEY UPDATE (without SET, but with ON as in JOIN .. ON) etc. Unlike other languages (e.g. Java), SQL keywords are only keywords in their contexts. That makes it a bit more difficult to format. With jOOQ supporting arbitrary vendor-specific extension, we're somewhere between SQL and PL/SQL, T-SQL. > In your case, you would also have the same issue with > free-style SQL anyway. It is safe to consider free-style SQL as "already formatted", at least for logging. > - When there is an opening parenthesis, start a new line and increase the > indentation, with an exception: parentheses with a single word. I've seen that ;-) Example: COUNT ( * ) > "pretty" is very subjective :) Of course. Well... We both know that "pretty printing" an accepted term for "formatting". Besides, I suspect that the formatting got lost, partially, in E-Mail re-formatting. But I agree with some points. A subquery's "select" should go to an indented new line > That probably means a formatting > strategy that the user can implement with predefined strategies. Yes. I've thought about that. I'll have to look into Eclipse's formatting rules eventually. But it's certainly not a priority. > This one is fine, except for the columns which I would prefer to see on the > same line. The fact that they are on multiple lines is probably interesting > here only because you prefix everything. Even without prefixing, imagine complex functions (e.g. window functions) and columns in the same projection list... Or projections with more than 20 fields... > I only process raw SQL, not query parts. How does your formatter work with > plain SQL? It is kept as such Cheers Lukas
