I've been poking into the syntax in gram.y, and finding
that the provision of parentheses for SELECT statements
is pretty broken.  I have previously posted examples of
odd things.  On closer examination, it appears to need
an overhaul.

There are two problems with this: (1) I'm new here, I don't
know the players and the protocols very well.  I don't
want to offend.  And (2) I don't have access to the SQL
standards so that we might get it right.  What I do have
is the Oracle docs, which may or may not have much to do
with how PostgreSQL ought to be, but it's worth noting
that parentheses are not allowed as freely as you might
suppose.

Little fixes here are going to get into trouble with yacc
because the current approach is so awkward.  It turns out
it's the reason Select Statements cannot be listed in a
CREATE RULE like the other kinds of commands.

Given a target syntax (like from the SQL standard) this
can be done in a day or so.  The question is: should it
happen, and if so what is the target syntax?

++ kevin


-- 
Kevin O'Gorman  (805) 650-6274  mailto:kogorman@pacbell.net
Permanent e-mail forwarder:  mailto:Kevin.O'Gorman.64@Alum.Dartmouth.org
At school: mailto:kogorman@cs.ucsb.edu
Web: http://www.cs.ucsb.edu/~kogorman/index.html
Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html

"There is a freedom lying beyond circumstance,
derived from the direct intuition that life can
be grounded upon its absorption in what is
changeless amid change" 
   -- Alfred North Whitehead

Thu, 26 Oct 2000 18:05:05 -0700
"Kevin O'Gorman" <kogorman@pacbell.net>
Select syntax (broken in current CVS tree)
"Kevin O'Gorman" <kogorman@pacbell.net> writes:
> I've been poking into the syntax in gram.y, and finding
> that the provision of parentheses for SELECT statements
> is pretty broken.  I have previously posted examples of
> odd things.  On closer examination, it appears to need
> an overhaul.

> There are two problems with this: (1) I'm new here, I don't
> know the players and the protocols very well.  I don't
> want to offend.

The existing handling of parens in SELECTs was done by me, a month
or so back.  I'm not satisfied with it, but decided that I couldn't
spend any more time on it right then.  If you can improve it, be
my guest.

> And (2) I don't have access to the SQL
> standards so that we might get it right.

The SQL spec is available (I haven't got a URL at hand but see the
list archives), but it really won't help you a lot in this case,
because the grammar it gives is clearly ambiguous.  The whole problem
here is to come up with a yacc-compatible grammar that does what we
want.

AFAIK our current grammar is correct in that (a) it requires parens
where they are required by the spec, and (b) it permits one level of
parens where they are permitted by the spec.  What it doesn't do is
permit redundant multiple levels of parens.

The other thing it doesn't do is allow ORDER BY or LIMIT in sub-selects,
only in a top-level SELECT statement.  This is correct per SQL92 spec,
but as I commented yesterday, I think we should ignore that spec
restriction henceforth.  It's possible that dropping that distinction
would make the paren situation easier to solve --- I did not consider
the possibility of doing that when I was hacking on it last month.

> Little fixes here are going to get into trouble with yacc
> because the current approach is so awkward.  It turns out
> it's the reason Select Statements cannot be listed in a
> CREATE RULE like the other kinds of commands.

No, the distinction between selects and other rule statements in CREATE
RULE is there for an entirely different reason: to enforce a semantic
restriction.  See past thread about whether multiple selects make sense
in a rule.  AFAIK the paren situation doesn't affect that.

> Given a target syntax (like from the SQL standard) this
> can be done in a day or so.  The question is: should it
> happen, and if so what is the target syntax?

The overall structure of the SQL-spec grammar is sufficiently different
from ours that I'm not sure we want to adopt it at all.  It's certainly
not going to be a one-day project if we try.

			regards, tom lane

Fri, 27 Oct 2000 11:19:52 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Select syntax (broken in current CVS tree) 