Re: Select syntax (broken in current CVS tree)

"Kevin O'Gorman" <kogorman(at)pacbell(dot)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