Parser doesn't grok unqualified array element

Has this come up before? 6.4.2 and current sources both have
this problem:

select count(*) from pg_proc where pg_proc.proargtypes[0] = 701;
works, but
select count(*) from pg_proc where proargtypes[0] = 701;
fails with ERROR: Unable to locate type name 'proargtypes' in catalog

The grammar doesn't seem to have a case that allows for a subscripted
attribute name without a relation name in front of it.

It looks like fixing this might be as easy as making the "ColId"
cases in a_expr, b_expr, possibly other places include an
opt_indirection item like columnElem does. But maybe there's
more to it than meets the eye?

No, it is that easy. For some reason, no one has done it yet. Our TODO
list has:

* array index references without table name cause problems

I am sure the complexity of yacc grammar rules have kept some away from
fixing this.

-- 
  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, Pennsylvania 19026

Has this come up before? 6.4.2 and current sources both have
this problem:
select count(*) from pg_proc where pg_proc.proargtypes[0] = 701;
works, but
select count(*) from pg_proc where proargtypes[0] = 701;
fails with
ERROR: Unable to locate type name 'proargtypes' in catalog

The grammar doesn't seem to have a case that allows for a subscripted
attribute name without a relation name in front of it.
It looks like fixing this might be as easy as making the "ColId"
cases in a_expr, b_expr, possibly other places include an
opt_indirection item like columnElem does. But maybe there's
more to it than meets the eye?

It has been reported, and is probably on the ToDo list as something. I
have been carrying it on my personal ToDo for a while, just to make
sure it doesn't get lost.

I would try your solution if I were fixing it, which I'm not yet. Go
fer it dude!

- Tom