| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Mike Blackwell <mike(dot)blackwell(at)rrd(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: RULE regression test fragility? |
| Date: | 2013-10-28 16:10:55 |
| Message-ID: | 4691.1382976655@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Oct 26, 2013 at 12:02 PM, Andres Freund <andres(at)2ndquadrant(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2013-10-28 16:11:32 | OSX doesn't accept identical source/target for strcpy() anymore |
| Previous Message | Robert Haas | 2013-10-28 16:08:18 | Re: PL/Python: domain over array support |