Ok, the ckeck for node being the first child already does the trick for standard l-t-r evaluation.Now the patch is *really* appended :-)
And rejected.
Well, to me it's not well-known that floating-point addition is not associative, do I need to re-learn my math?You cannot assume that an operator is commutative or associative just because it has a name you think ought to be. (For a counter-example, it's well known that floating-point addition is not associative.)
In this case the user really wrote the parentheses, so they should be shown.More: if the tree structure for ops of equal precedence looks like a + (b + c), then it's a near certainty that the user wrote those parentheses. Why would you think that removing them is pretty-printing?
This stuff is all about guessing what the original definition looked like, if we just had the source <sigh>...
I had a conversation with Bruce about embedded comments, and we found that the idea of (mis-)using nodes for this seems to be not viable. Still seeking for a way to preserve more-or-less the original user's definition.
Regards, Andreas
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
