"Nikolay Samokhvalov" <samokhvalov@gmail.com> writes:
> As I can see here, when I ask for element that doesn't exist, the
> database returns NULL for me. Maybe it's well-known issue (and
> actually I understood this behaviour before), but strictly speaking it
> seems wrong for me: the database _knows_ that there is no element, so
> why NULL?
This is operating as designed, per
http://www.postgresql.org/docs/8.2/static/arrays.html
: 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 schedule currently has the dimensions
: [1:3][1:2] then referencing schedule[3][3] yields NULL. Similarly, an
: array reference with the wrong number of subscripts yields a null rather
: than an error.
AFAIR it's always been like that, so changing it seems exceedingly
likely to break some peoples' applications. It's not completely without
analogies in SQL, anyway: consider the behavior of INSERT when fewer
columns are provided than the table has. Pretending that elements
outside the stored range of the array are null is not all that different
from silently adding nulls to a row-to-be-stored.
regards, tom lane