I spent some time today trying to persuade the grammar to accept
unadorned array subscripting, ieSELECT arraycolname[2] FROM table;
rather than what you have to do in 6.5:SELECT table.arraycolname[2] FROM table;
It's easy enough to add "opt_indirection" to the rules that use ColId,
but I find one ends up with a bunch of reduce/reduce conflicts.
The basic problem is that at the start of an expression, the inputident [
could be the beginning of a Typename with subscripts, or it could be
a column name with subscripts. The way the grammar is constructed,
the parser has to reduce the ident to either ColId or a typename
nonterminal before it can shift the '[' ... and there's no way to
decide which.
Now how did Typename get into the picture? There is one rule that
is the culprit, namely "AexprConst ::= Typename Sconst". Without
that rule, a type name never appears at the start of an expression
so there is no conflict.
I can see three ways to proceed:
1. Forget about making arrays easier to use.
2. Remove "AexprConst ::= Typename Sconst" from the grammar. I do
not believe this rule is in SQL92. However, we've recommended
constructions like "default text 'now'" often enough that we might
not be able to get away with that.
3. Simplify the AexprConst rule to only allow a subset of Typename
--- it looks like forbidding array types in this context is enough.
(You could still write a cast using :: or AS, of course, instead of
"int4[3] '{1,2,3}'". The latter has never worked anyway.)
I'm leaning to choice #3, but I wonder if anyone has a better idea.
regards, tom lane