]> granicus.if.org Git - postgresql/commit
Fix grammar for subscripting or field selection from a sub-SELECT result.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 30 Jan 2013 19:16:51 +0000 (14:16 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 30 Jan 2013 19:16:51 +0000 (14:16 -0500)
commitb3e715a035dad28aeb6e64dd39cebd72cacc44b8
treeec29d19f2b6b97d3c7931bb522fa32a161846c66
parentfe738d77f136a230d1d11310a4290e31a9fafb5c
Fix grammar for subscripting or field selection from a sub-SELECT result.

Such cases should work, but the grammar failed to accept them because of
our ancient precedence hacks to convince bison that extra parentheses
around a sub-SELECT in an expression are unambiguous.  (Formally, they
*are* ambiguous, but we don't especially care whether they're treated as
part of the sub-SELECT or part of the expression.  Bison cares, though.)
Fix by adding a redundant-looking production for this case.

This is a fine example of why fixing shift/reduce conflicts via
precedence declarations is more dangerous than it looks: you can easily
cause the parser to reject cases that should work.

This has been wrong since commit 3db4056e22b0c6b2adc92543baf8408d2894fe91
or maybe before, and apparently some people have been working around it
by inserting no-op casts.  That method introduces a dump/reload hazard,
as illustrated in bug #7838 from Jan Mate.  Hence, back-patch to all
active branches.
src/backend/parser/gram.y
src/test/regress/expected/subselect.out
src/test/regress/sql/subselect.sql