Re: I believe it will (was Re: Hmm, will this do?)

I've taken another look at this stuff. I think it's a big improvement, but
we didn't notice that it does NOT do the thing we set out to. You
still cannot say
select foo union (((select bar)))

and as I think about it, there's no way to allow that without unifying
with c_expr. Consider: yacc is a bottom-up parser, with limited
look-ahead. So when it sees
"(((select bar)" and it has just turned it into
"(((SelectStmt)" what is it going to reduce next? It has one
char of lookahead, so it can peek out to
"(((SelectStmt))" but it still doesn't know what to reduce.
It could be that what is wanted is either of
"((c_expr)" or "((some_select_type)"
and guessing is not allowed.... :-)

I have experimented with unifying c_expr and selects, and it is
all kinds of messy, because to the parser it appears that you're
introducing all sorts of expression tokens into the Select syntax.
Of course we would reject all such strings for other reasons, but
poor yacc has no way of knowing that.

I'm afraid that for now, we should accept the improvements that
have been achieved, and consider a more general treatment of
parentheses later.

What do you think?

++ kevin

On Sun, 29 Oct 2000, Kevin O'Gorman wrote:
>
> That was very helpful. And I was able to eliminate most of the
> remaining restrictions by letting a SelectStmt be EITHER
> a) a simple_select (which has no top-level parens or qualifiers)
> or
> b) a select_clause with at least one qualifier.
> Option b reintroduces the SORT and LIMIT operations at the
> top level, outside parentheses.
>
> The remaining restriction that is not SQL92 is that a SelectStmt
> may not have wholly inclusive parens -- there has to be something
> outside of them. If they're really important, one way to do it would
> be to say an OptimizableStmt can be a c_expr, and check that it
> has a top-level SelectStmt or SetOperationStmt, then treat it as
> a Select Statement.
>
> I also made mods to put the top-level sort,limit and forUpdate in the
> top-level node of the tree. In order to make this be workable, I also
> modified parsenodes.h so that the structure for SetOperationStmt is a
> synonym for SelectStmt, and merged the fields of the two node
> types.
>
> I've attached diffs from the current tip of the tree (as of this morning).
> These are still not completely functional until the downstream code
> is changed too, of course.
>
>
> On Sat, 28 Oct 2000, you wrote:
> > After some more experimentation, I found that gram.y can be modified
> > per the attached diffs to yield a conflict-free grammar that allows
> > redundant parens and ORDER/LIMIT in subclauses. The remaining
> > restrictions are:
> >
> > * To attach ORDER/LIMIT to a member select of a UNION/INTERSECT/EXCEPT,
> > you need to write parens, eg
> > (SELECT foo ORDER BY bar) UNION SELECT baz;
> > SELECT foo UNION (SELECT bar ORDER BY baz);
> > In the second case the parens are clearly necessary to distinguish the
> > intent from attaching the ORDER BY to the UNION result. So this seems
> > OK to me.
> >
> > * Parens cannot separate a select clause from its ORDER/LIMIT clauses.
> > For example, this is not allowed:
> > (SELECT foo FROM table) ORDER BY bar;
> >
> > The latter restriction is pretty annoying, first because SQL92 says
> > it should be legal, and second because we used to accept it. However,
> > it might be an acceptable tradeoff for allowing ORDER in subselects.
> > Thoughts?
> >
> > BTW these diffs are just proof-of-concept for the grammar being
> > conflict-free; I haven't changed the output structures, so don't
> > try to run the code!
> >
> > regards, tom lane
>

--
Kevin O'Gorman (805) 650-6274 mailto:kogorman(at)pacbell(dot)net
Permanent e-mail forwarder: mailto:Kevin.O'Gorman(dot)64(at)Alum(dot)Dartmouth(dot)org
At school: mailto:kogorman(at)cs(dot)ucsb(dot)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