Tom Lane <tgl@sss.pgh.pa.us> writes:
> Greg Stark <gsstark@mit.edu> writes:
> > Hm, this seems odd
>
> > slo=> select b,b[0],b[0][0] from t;
> > b | b | b
> > -----------------------------------------------+------------------------+---
> > (-75.493906,44.854114),(-75.493906,44.854114) | (-75.493906,44.854114) |
> > (1 row)
>
> The problem here is that foo[m][n] is our notation for a
> doubly-subscripted array --- and we don't have any concept in the type
> system that a one-dimensional array is different from a two-dimensional
> array. So the code goes down the primrose path of assuming that "b"
> is a 2-D array of points, rather than expecting b[0] to yield a
> separate datatype that should be separately subscripted.
I guess arrays must be some deep voodoo. [] doesn't show up in the list of
operators. I would be happy if there was at least some way to trick the parser
into doing the right thing. I'm surprised something like this doesn't work:
slo=> select (b[0])[0] from t;
ERROR: parser: parse error at or near "[" at character 14
> We could perhaps hack something for this particular case, since box is
> known not to be a general array but only a hardwired one-dimensional
> array of points. I don't see a good general solution though.
> Any thoughts?
If [] were a normal operator then other datatypes could define operations
similar to point and box, but I imagine it's the way it is for some good
reason in the parser level.
--
greg
