Re: [HACKERS] Arrays versus 'type constant' syntax

> I spent some time today trying to persuade the grammar to accept
> unadorned array subscripting, ie
> SELECT 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.

You know, that has been on the TODO list for a long time, so I should
have guessed it was some tricky problem.

> The basic problem is that at the start of an expression, the input
> ident [
> 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.

This reminds me of C grammar, where the scanner has to be able to ask
the grammar if a token is a type or not, because typedef can create its
own types. This is why C grammar/scanning is not totally simple. We
have avoided that complexity so far.

> 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.

That is quite interesting.

> 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.

Yes, if it is easy, #3 sounds good. This is a very rarly used area of
the grammer, so any restriction on Arrays and Casting will probably
never be hit by a user, though there are so many users, I am sure
someone will find it soon enough.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026