Re: Precedence of standard comparison operators

Robert Haas <robertmhaas@gmail.com> writes:
> Just out of curiosity, does this change create a dump-and-reload
> hazard?  Like if I pg_upgrade my cluster, will the output of pg_dump
> potentially be sufficiently under-parenthesized that reload will
> create a non-equivalent database?

No.  Had there been any such hazard, I would not have been nearly
as enthused about this project.

In the first place, pg_dump disables ruleutils' pretty-printing
heuristics, so that you always get fully parenthesized expressions
no matter what.  I insisted on that years ago, in the expectation
that we might someday need to do things like this patch; it's
always acted that way, in every release that had any pretty-printing
ability at all.  For example,

regression=# create view vv as select unique1 + unique2*four as x from tenk1;
CREATE VIEW
regression=# \d+ vv                  View "public.vv"Column |  Type   | Modifiers | Storage | Description 
--------+---------+-----------+---------+-------------x      | integer |           | plain   | 
View definition:SELECT tenk1.unique1 + tenk1.unique2 * tenk1.four AS x  FROM tenk1;

regression=# \q
$ pg_dump -t vv regression
...
CREATE VIEW vv ASSELECT (tenk1.unique1 + (tenk1.unique2 * tenk1.four)) AS x  FROM tenk1;


In the second place, AFAICS ruleutils' heuristics do not know anything
about any of the constructs affected by this patch, and so they'll be
fully parenthesized anyway, even in pretty-printed output.
For example:

regression=# create view vvv as select 1+2 is distinct from 42 as q;
CREATE VIEW
regression=# \d+ vvv                 View "public.vvv"Column |  Type   | Modifiers | Storage | Description 
--------+---------+-----------+---------+-------------q      | boolean |           | plain   | 
View definition:SELECT (1 + 2) IS DISTINCT FROM 42 AS q;

The parens are unnecessary, but ruleutils doesn't know that, so
it puts them in.
        regards, tom lane