]> granicus.if.org Git - postgresql/commit
Okay, here's my attempt at fixing the problems with parentheses in
authorBruce Momjian <bruce@momjian.us>
Sat, 28 Oct 2000 15:44:04 +0000 (15:44 +0000)
committerBruce Momjian <bruce@momjian.us>
Sat, 28 Oct 2000 15:44:04 +0000 (15:44 +0000)
commit2f4c9d39febec0c092388b124bf3de2d857eb5a9
tree222317c8588985e667f005ca007916009bbc067b
parent3eb9b73718f1d14ff3f4cc005fa7c665995c5a77
Okay, here's my attempt at fixing the problems with parentheses in
subqueries.  It passes the normal 'runcheck' tests, and I've tried
a few simple things like
  select 1 as foo union (((((select 2))))) order by foo;

There are a few things that it doesn't do that have been talked
about here at least a little:

1) It doesn't allow things like "IN(((select 1)))" -- the select
here has to be at the top level.  This is not new.
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.

I have preserved the ability, used in the regression tests, to
have a single select statement in what appears to be a RuleActionMulti
(but wasn't -- the parens were part of select_clause syntax).
In my version, this is a special form.

This may cause some discussion: I have differentiated the two kinds
of RuleActionMulti.  Perhaps nobody knew there were two kinds, because
I don't think the second form appears in the regression tests. This
one uses square brackets instead of parentheses, but originally was
otherwise the same as the one in parentheses.  In this version of
gram.y, the square bracket form treats SELECT statements the same
as the other allowed statements.  As discussed before on this list,
psql cannot make sense out of the results of such a thing, but an
application might.  And I have designs on just such an application.

++ kevin o'gorman
src/backend/parser/gram.y