Re: A rare error

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