Re: Array behavior oddities

From: Jens-Wolfhard Schicke <drahflow(at)gmx(dot)de>
To: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Array behavior oddities
Date: 2008-01-16 10:23:10
Message-ID: 478DDB0E.3040004@gmx.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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-----

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2008-01-16 10:28:12 Re: to_char incompatibility
Previous Message Gokulakannan Somasundaram 2008-01-16 08:38:33 Re: WAL logging of hash indexes