| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | 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-26 16:25:40 |
| Message-ID: | 16696.1382804740@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-10-26 11:27:19 -0400, Tom Lane wrote:
>>> +1 (but what are those silly parens in pg_seclabels definition?),
>>
>> That looks weird to me too, but it's surely not the fault of this patch.
>> Maybe we should take a look at exactly what ruleutils is doing there.
> 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.
I'm not objecting to the parens being there, but I think the layout
doesn't look nice. Not immediately sure what would look better though.
Obvious alternatives include one line per paren:
(
(
(
SELECT ...
or getting rid of the space between parens:
(((SELECT ...
but I'm not sure I'm thrilled with either of those. Thoughts?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2013-10-26 17:07:09 | Re: RULE regression test fragility? |
| Previous Message | Andres Freund | 2013-10-26 16:02:18 | Re: RULE regression test fragility? |