Re: Precedence of standard comparison operators

Robert Haas <robertmhaas(at)gmail(dot)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 AS
SELECT (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