All,
I have configured the formatter to stack conditions for multi-predicate tests.
Stacking arrangement is: operators left, all conmditionas aligned.
This results in all conditions being aligned on the first operand of each line. Like this:
Is there a way to request the formatter to not only align the first operand but also the operators and the second operands. Like this:
Cannot currently be done but it’s an interesting idea.
I wrote some experimental code that yields the following formatted result:
BEGIN
SELECT x
INTO z
FROM y
WHERE a = b
AND cccccccc = d
AND e = fffffffffff
AND ggg = hhh
OR a = b
AND ccccccccccccccccccccccccccc = d
AND e = fffffffffff
AND ggg = hhh
OR uuuuuuuuuuuuuuuuuuuuuu = v
OR w = t;
a := 1;
bbbbbbbbbbbb := 2;
c := 333333333333;
END;
This is just experimental, options need to be added and there’s more to it, but the idea works.
I’ve queued it as an enhancement request (QP-1012).
Andre, thanks.
looks good to me. This greatly enhances readability of the code!
Will it work for ON clauses as well?
Abe.
===
Abe, it would work for anything that contains AND/OR/XOR expressions.
Andre
Andre,
just to take it a step further: how will you treat operators of more than 1 character?
E.g. <>, is not null, between.
And how will the AND keyword in a between predicate be handled?
Can you prevent that one from being stacked?
Kind regards,
Abe
===
Here’s where the fun comes in. Expressions come in many flavors. We could do something like this:
WHERE a = b
AND cccccccc = d
AND e <> fffffffffff
AND z NOT IN (u, v, w)
AND k BETWEEN lll AND mmm
AND r BETWEEN ssssssssssssssssssssssssssssssssssssssssssssssss
AND tttttttttttttttttttttttttttttt
But it’s mainly a matter of taste, of course.
Andre
Andre,
I was actually thinking of:
That is:
I am aware that you will have to strike a balance with regard to the number of formatting options to support in the sense that an extensive set of supported options will require more code with a higher level of complexity, with the associated price tag of more defects and more time required for support. I’m merely sketching my ideal, and will leave it up to you to decide what is doable and supportable.
I like the way that looks. I can see using that kind of option. It makes it super easy to see the values that are being filtered on.
On Thu, Apr 23, 2015 at 1:40 AM, kornelis.abe bounce-kornelisabe@toadworld.com wrote:
Reply by kornelis.abe
Andre,
I was actually thinking of:
That is:
- right-aligned block of keywords
- left-aligned block of first operands
- right-aligned block of operators
- left-aligned block of second operands
- if line wrap occurs in a list of items, try to align the items (left-aligned for char literals, decimal-aligned for numerics)
I am aware that you will have to strike a balance with regard to the number of formatting options to support in the sense that an extensive set of supported options will require more code with a higher level of complexity, with the associated price tag of more defects and more time required for support. I'm merely sketching my ideal, and will leave it up to you to decide what is doable and supportable.
Kind regards,
Abe
To reply, please reply-all to this email.
Stop receiving emails on this subject.
Or Unsubscribe from Toad for Oracle - Beta notifications altogether.
Toad for Oracle - Beta Discussion Forum
Flag this post as spam/abuse.
--
Phyllis Helton
Data Magician
Digital Strategies, Cru | Data Sciences & Analytics
Office 
407-515-4452
