Alternative formatting

I know I can switch between formatting rules but in daily work it's not comfy, especially if repeated for common cases described below

We often need different formatting rules based on length of some part of sql. For example number of function arguments.
If there are no arguments, or the is single argument we want to leave it in the same line as function:

	Code:
	CREATE OR REPLACE FUNCTION someschema.somefunction() (...) or CREATE OR REPLACE FUNCTION someschema.somefunction(arg INTEGER) (...)

But in if there are more arguments we want to put them into separate block under function name

	Code:
	CREATE OR REPLACE FUNCTION someschema.somefunction ( arg1 INTEGER, arg2 INTEGER etc ) (...)

Very similar situation for selects:
If there is only asterisk or a few fields queried, then it looks better inline with SELECT keyword. If there are more fields, it's better to format them line by line

	Code:
	SELECT somefield FROM sometable WHERE ... vs SELECT somefield_1, somefield_2, somefield_3, somefield_4, somefield_5, somefield_6 FROM sometable WHERE ...

I suspect there are more similar scenarios, like length of IF condition, number of fields in INSERT query etc.

Did you consider improving this area of SA, making formatting more automated (without need of switching between formatting rules for specific lines of code)?
It would decide the formating rules by length of line or number of elements. Maybe it would interactively ask about proper rule to be applied. Just ideas.

with regards

You don't have to "switch", I assume you mean changing default style in the options.
You can "choose" which one to apply if instead of Ctrl+F11, you press Ctrl+Shift+F11. If you have multiple styles defined, you can choose which one you want to apply to the selected text.

Did I get correctly what you are after?

By "switching" I meant selecting formatting using CTRL+F11.
But in scenarios I have in my mind, it's not efficient. In case we have to format a more complex function or script containing multiple queries where every single one requires different formatting style changing formatting is time demanding. It's quicker to do it manually instead of using SA and correcting its work after.

All I'm asking for are conditions which could be evaluated to chose the best fitting formatting style.

with regards

The code formatting engine is based on more or less generic SQL matching patterns. If say, a pattern is defined such that a starting "(" bracket is wrapped, the code formatter would execute it as defined. If it's defined to keep "( and whatever follows it in the same line, it won't wrap it. If theoretically there is a separate generic pattern for "(..., ...)" defined without other keywords as anchors, it will wrap text according to that pattern regardless of where it's used, in a function declaration or table definition. You can define multiple patterns, as many as you want, and they can be applied in a certain order, for example, first apply CREATE OR REPLACE FUNCTION... etc, and then apply "(...)", but there is a limit to that.

I'm afraid what you are asking goes beyond such capabilities. It needs an element of AI or some hard-coded logic for each type of SQL statement, for example, specifically for PostgreSQL for CREATE OR REPLACE function and for CREATE function, etc... counting arguments in a function, deciding if together with arguments or without arguments it should have the arguments wrapped or not. But what if there is a long user defined domain name or long default value? That wrapping decision should be intelligent, maybe individual in each case, better be done manually to user liking the result.

The formatter primarily address 3 needs
1. Convert hard to read machine generated SQL code and make it human readable.
2. Beatify code written by non-professional developers.
3. Help with uniform code formatting of code developed by a team of developers so that the resulting code looks consistent.

Last edited by SysOp on Wed Jun 13, 2018 2:43 am; edited 1 time in total

I now it's not trivial. I though you might consider it in future anyway.
Thanks for the answer.