Re: Array behavior oddities - Mailing list pgsql-hackers

From Jens-Wolfhard Schicke
Subject Re: Array behavior oddities
Date
Msg-id 478DDB0E.3040004@gmx.de
Whole thread Raw
In response to Array behavior oddities  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruce Momjian wrote:
>   An array subscript expression will return null if either the array itself
>   or any of the subscript expressions are null.  Also, null is returned
>   if a subscript is outside the array bounds (this case does not raise an
>   error).  For example, if <literal>schedule</> currently has the
>   dimensions <literal>[1:3][1:2]</> then referencing
>   <literal>schedule[3][3]</> yields NULL.  Similarly, an array reference
>   with the wrong number of subscripts yields a null rather than an error.
> 
>   An array slice expression likewise yields null if the array itself or
>   any of the subscript expressions are null.  However, in other corner
>   cases such as selecting an array slice that is completely outside the
>   current array bounds, a slice expression yields an empty
>   (zero-dimensional) array instead of null.  If the requested slice
>   partially overlaps the array bounds, then it is silently reduced to just
>   the overlapping region.
> 
> Is there a reason out-of-bounds array accesses behave differently for
> slices and non-slices?
> 
> Having slices and non-slices behave differently is very confusing to me.
I think the case of partially-out-of-bound slices is a good reason to have
this difference:

fastgraph=# select ('{foo,bar}'::text[])[1:2];  text
- -----------{foo,bar}
(1 row)

fastgraph=# select ('{foo,bar}'::text[])[2:3];text
- -------{bar}
(1 row)

fastgraph=# select ('{foo,bar}'::text[])[3:4];text
- ------{}
(1 row)

We cannot return an empty array in case of unsliced out-of-bounds access
because the type wouldn't match at all.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHjdsOzhchXT4RR5ARAvBvAKCGVxgl6u2ZUcB/Bvl2jPN2/p6hzACdFXE3
9w01URr/xPYukzHhD5qhudE=
=iZxq
-----END PGP SIGNATURE-----


pgsql-hackers by date:

Previous
From: "Gokulakannan Somasundaram"
Date:
Subject: Re: WAL logging of hash indexes
Next
From: Peter Eisentraut
Date:
Subject: Re: to_char incompatibility