Re: Gram.y patches for better parenthesis handling.

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

In response to

Browse pgsql-hackers by date

  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