On Mon, Oct 28, 2013 at 12:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sat, Oct 26, 2013 at 12:02 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>>> Imo what it does looks sane - it adds parentheses whenever a child of a
>>> set operation is a set operation again to make sure the order in which
>>> the generated set operations are parsed/interpreted stays the same.
>
>> But UNION ALL is associative.
>
> In theory, yeah.
>
> In practice, this could for example affect the parser's choices of
> column datatypes for the UNION result. We could perhaps side-step
> that by forcing datatype labeling in the UNION arms, but I'm not
> prepared to bet that ruleutils' output would be right if we just
> summarily removed the parentheses.
Well, if it were actually associative, then A UNION ALL B UNION ALL C
would be equivalent to either A UNION ALL (B UNION ALL C) or (A UNION
ALL B) UNION ALL C. But even if it's *NOT* associative, it must be
equivalent to one of those. (If not, then including the parentheses
in the output is wrong.) So we could leave the parentheses out in
whichever case it's equivalent to.
I don't feel strongly that this has to be done; it's obviously not a
project priority. But if we're uncomfortable about the way that these
constructs are being formatted during deparsing, eliminating
unnecessary nesting levels could potentially help. I fairly commonly
write queries that involve multiple UNION ALL branches and, no matter
how clever we are, having that lead to progressively deeper nesting at
each level is not going to look nice.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
