Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-10-28 05:15:40
Subject: Re: Re: [GENERAL] A rare error
Previous:From: Stephan SzaboDate: 2000-10-28 04:12:59
Subject: Re: Can't import date using copy

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group