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@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026