Re: [GENERAL] A rare error

pgsql-hackers-owner(at)hub(dot)org wrote:

I've been looking into this. I thought it would be easy, but it
doesn't want an easy fix, because it's worse than it at first
appeared.

Were you aware that this is legal:
(select avg(a),b from dummy group by b) order by b;
but this is not:
(select avg(a),b from dummy) group by b order by b;
and if we just allowed lots of nested parens, we would allow:
((((select avg(a),b from dummy group by b)))) order by b;
which just seems silly.

I for one don't like any of these, although I prefer the
one that is currently disallowed -- and it appears to me
that the parens being allowed in select_clause are being
introduced at the wrong level. I'm going to experiment
some with the concept of a "select_term" which will be the
thing that can be parenthesized (in some contexts).

BTW: yacc accepts LALR grammars, which are fairly restricted.
Thus the shift/reduce complaints and such don't mean it's
ambiguous, just that it's pushing the envelope of the LALR
paradigm. A lot of yacc grammars do just that, and work
just fine, but of course you have to know what you're doing.
I don't, at least not to that level of wizardry, so I'll stay
away from shift/reduce, etc. I mention it just to say that
we're not treading on ambiguity here, just the limits of yacc.

Finally, I hereby solicit comments. Because of yacc's limits,
it may turn out to be difficult to do things like have
unlimited parens around a "select_term" and also have
constructs like
NOT IN (select_term)
because yacc might not know how to parse the outer parens.
OTOH, maybe we don't want NOT IN (((SELECT foo FROM bar))).
OTOOH, maybe we do because there could be program-generated
SQL out there that would like that freedom. What do the
readers think?

I don't know yet where the problems could be. I may need
help figuring out what's important to provide and what is
less so. Does anyone know if there are a lot of parens in
the regression tests?

++ kevin

>
> Subject: Re: [GENERAL] A rare error
> Date: Wed, 25 Oct 2000 12:28:35 -0400
> From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> To: DaVinci <bombadil(at)wanadoo(dot)es>
> CC: Lista PostgreSql <pgsql-general(at)postgresql(dot)org>,
> pgsql-hackers(at)postgresql(dot)org
> References: <20001025104758(dot)A7643(at)fangorn(dot)net>
>
> DaVinci <bombadil(at)wanadoo(dot)es> writes:
> > An extrange behavior with PostgreSql 7.0.2:
> > select * from foo where exists
> > (select * from foo)
> > works fine. But:
> > select * from foo where exists
> > ((select * from foo))
> > shows an error:
> > ERROR: parser: parse error at or near "("
> > Is this a bug?
>
> I was fooling around with exactly that point a couple weeks ago. You'd
> think it would be easy to allow extra parentheses around a sub-select,
> but I couldn't figure out any way to do it that didn't provoke shift/
> reduce conflicts or worse.
>
> The main problem is that if parentheses are both part of the expression
> grammar (as they'd better be ;-)) and part of the SELECT grammar then
> for a construct like
> select (((select count(foo) from bar)));
> it's ambiguous whether the extra parens are expression parens or part
> of the inner SELECT statement. You may not care, but yacc does: it does
> not like ambiguous grammars. AFAICS the only solution is not to allow
> parentheses at the very top level of a SELECT structure. Then the above
> is not ambiguous because all the extra parens are expression parens.
>
> This solution leads directly to your complaint: the syntax is
> EXISTS ( SELECT ... )
> and you don't get to insert any unnecessary levels of parenthesis.
>
> We could maybe hack something for EXISTS in particular (since we know
> a parenthesized SELECT must follow it) but in the general case there
> doesn't seem to be a way to make it work. For example, in current
> sources this is OK:
> select * from foo where exists
> ((select * from foo) union (select * from bar));
> but not this:
> select * from foo where exists
> ((select * from foo) union ((select * from bar)));
> ERROR: parser: parse error at or near ")"
>
> If there are any yacc hackers out there who think they can improve on
> this, please grab gram.y from current CVS and have at it. It'd be nice
> not to have an artificial restriction against redundant parentheses in
> SELECT structures.
>
> 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