[Fwd: Re: [PATCHES] ruleutils with pretty-print option]
Now the patch is *really* appended :-) Tom Lane wrote: Applied with some editorializing. In particular, I don't believe the original did the right thing with (a - (b - c)). Oops, missed that case... But now, we have (a + ( b + c)) again. A patch that removes parentheses for + and * is appended. Regards, Andfdsa Index: backend/utils/adt/ruleutils.c === RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/adt/ruleutils.c,v retrieving revision 1.147 diff -c -r1.147 ruleutils.c *** backend/utils/adt/ruleutils.c 30 Jul 2003 22:56:23 - 1.147 --- backend/utils/adt/ruleutils.c 31 Jul 2003 09:32:15 - *** *** 2547,2552 --- 2547,2559 if (node == (Node *) lfirst(((OpExpr *) parentNode)-args)) return true; + /* + * Exception: for * and +, ordering doesn't matter + */ + if ((*op == '+' *parentOp == '+') || + (*op == '*' *parentOp == '*')) + return true; + return false; } /* else do the same stuff as for T_SubLink et al. */ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [Fwd: Re: [PATCHES] ruleutils with pretty-print option]
Tom Lane wrote: Now the patch is *really* appended :-) And rejected. Ok, the ckeck for node being the first child already does the trick for standard l-t-r evaluation. 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.) Well, to me it's not well-known that floating-point addition is not associative, do I need to re-learn my math? 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? In this case the user really wrote the parentheses, so they should be shown. 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
Re: [Fwd: Re: [PATCHES] ruleutils with pretty-print option]
Andreas Pflug [EMAIL PROTECTED] writes: Well, to me it's not well-known that floating-point addition is not associative, do I need to re-learn my math? regression=# select (1.0::float8 + (-1.0::float8)) + 1.0e-20::float8; ?column? -- 1e-20 (1 row) regression=# select 1.0::float8 + ((-1.0::float8) + 1.0e-20::float8); ?column? -- 0 (1 row) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
