Robert Haas <robertmh...@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 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
