From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | kogorman(at)pacbell(dot)net |
Cc: | PGSQL Hackers List <pgsql-hackers(at)hub(dot)org> |
Subject: | Re: Gram.y patches for better parenthesis handling. |
Date: | 2000-10-28 04:55:40 |
Message-ID: | 6784.972708940@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Kevin O'Gorman" <kogorman(at)pacbell(dot)net> writes:
> 2) It does NOT preserve the odd syntax I found when I started looking
> at this, where a SELECT statement could begin with parentheses. Thus,
> (SELECT a from foo) order by a;
> fails.
Um, as a general rule that's not an acceptable limitation. Consider
(SELECT foo EXCEPT SELECT bar) INTERSECT SELECT baz;
Without parens this will mean something quite different, since
INTERSECT has higher precedence than EXCEPT.
Also, a leading paren is clearly legal according to SQL92 --- trace
for example the productions
<direct select statement: multiple rows>
<query expression>
<non-join query expression>
<non-join query term>
<non-join query primary> ::=
<left paren> <non-join query expression> <right paren>
(UNION/EXCEPT structures are <non-join query expression> in this
hierarchy.)
The reason that making this grammar yacc-compatible is so hard is
precisely that leading parens must sometimes be part of the SELECT
structure, whereas extraneous parens need to be kept out of it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-10-28 05:15:40 | Re: Re: [GENERAL] A rare error |
Previous Message | Stephan Szabo | 2000-10-28 04:12:59 | Re: Can't import date using copy |