Reduce indentation/parenthesization of set operations in rule/view dumps.
A query such as "SELECT x UNION SELECT y UNION SELECT z UNION ..."
produces a left-deep nested parse tree, which we formerly showed in its
full nested glory and with all the possible parentheses. This does little
for readability, though, and long UNION lists resulting in excessive
indentation are common. Instead, let's omit parentheses and indent all
the subqueries at the same level in such cases.
This patch skips indentation/parenthesization whenever the lefthand input
of a SetOperationStmt is another SetOperationStmt of the same kind and
ALL/DISTINCT property. We could teach the code the exact syntactic
precedence of set operations and thereby avoid parenthesization in some
more cases, but it's not clear that that'd be a readability win: it seems
better to parenthesize if the set operation changes. (As an example,
if there's one UNION in a long list of UNION ALL, it now stands out like
a sore thumb, which seems like a good thing.)
Back-patch to 9.3. This completes our response to a complaint from Greg
Stark that since commit 62e666400d there's a performance problem in pg_dump
for views containing long UNION sequences (or other types of deeply nested
constructs). The previous commit 0601cb54dac14d979d726ab2ebeda251ae36e857
handles the general problem, but this one makes the specific case of UNION
lists look a lot nicer.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/41de93c53aa941167d445ecb7d91d58829adcc92
Modified Files
--------------
src/backend/utils/adt/ruleutils.c | 81 +++++---
src/test/regress/expected/create_view.out | 274 +++++++++++++--------------
src/test/regress/expected/matview.out | 24 +--
src/test/regress/expected/rules.out | 290 ++++++++++++++---------------
src/test/regress/expected/with.out | 84 ++++-----
5 files changed, 390 insertions(+), 363 deletions(-)