Re: [Fwd: Re: ruleutils with pretty-print option] - Mailing list pgsql-patches

From Andreas Pflug
Subject Re: [Fwd: Re: ruleutils with pretty-print option]
Date
Msg-id 3F2927F9.6080402@pse-consulting.de
Whole thread Raw
In response to [Fwd: Re: ruleutils with pretty-print option]  (Andreas Pflug <pgadmin@pse-consulting.de>)
Responses Re: [Fwd: Re: ruleutils with pretty-print option]  (Manfred Koizar <mkoi-pg@aon.at>)
Re: [Fwd: Re: ruleutils with pretty-print option]  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
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


pgsql-patches by date:

Previous
From: Manfred Koizar
Date:
Subject: Re: Proof-of-concept for initdb-time shared_buffers selection
Next
From: Tom Lane
Date:
Subject: Re: Check for failed memory allocations in libpq