Thread: BUG #2212: Extracting array from 2 dim array may be incorrect

The following bug has been logged online:

Bug reference:      2212
Logged by:          Walter Roeland
Email address:      wroeland@marcatel.net
PostgreSQL version: 8.1.2
Operating system:   Windows XP professional
Description:        Extracting array from 2 dim array may be incorrect
Details:

Select (Array[5,8,1])[2] as E;
returns 8 (ok, dimension is lowerd from 1 to 0).

Select (Array[Array[3,2,2],Array[7,4,4],Array[5,8,1]])[3:3] as V;
returns {{5,8,1}} (I suppose this is ok, same dimension).

But:
Select (Array[Array[3,2,2],Array[7,4,4],Array[5,8,1]])[3] as V;
Returns Null, as far I understand it should return {5,8,1}, i.e. lowering
dimension from 2 to 1.

Note: the documentation is not specific about when extracting an element
lowers the dimension (eg. using [2]) and when not (e.g. using [2:2]).

"Walter Roeland" <wroeland@marcatel.net> writes:
> Select (Array[5,8,1])[2] as E;
> returns 8 (ok, dimension is lowerd from 1 to 0).

> Select (Array[Array[3,2,2],Array[7,4,4],Array[5,8,1]])[3:3] as V;
> returns {{5,8,1}} (I suppose this is ok, same dimension).

> But:
> Select (Array[Array[3,2,2],Array[7,4,4],Array[5,8,1]])[3] as V;
> Returns Null, as far I understand it should return {5,8,1}, i.e. lowering
> dimension from 2 to 1.

The current rule is that if you write an array slice subscript (ie,
use ":" in at least one of the subscripts), you get an array out.
If you don't write ":", you get a single element out.  We cannot
really change this on-the-fly, because the result type of the
expression has to be determinable at parse time.  (If the exact number
of dimensions of an array were part of its type signature, we could
do what you're imagining, but it's not: all arrays over the same base
type have the same type, and dimensionality is strictly a run-time
thing.)

I can see the argument for raising an error, instead of returning NULL,
when the number of subscripts isn't compatible with the number of
dimensions.  But I'm not sure it's worth taking any
backward-compatibility risks for...

            regards, tom lane