On 4/9/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Nikolay Samokhvalov" <[EMAIL PROTECTED]> 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?
[...]
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.
OK, I see.
But if I try to INSERT to column that doesn't exist in the table, I
have an error.
Why pg's arrays are designed so that postgres doesn't produce errors
for attempts to access nonexistent element of array? Why there is no
simple sanity check (SELECT (ARRAY[6,8])[-1] -- works w/o an error)? I
remember several cases when people (e.g. me :-) ) were spending some
time trying to find an error in some pl/pgsql function and the reason
lied in incorrect work with arrays (i.e. messages like "index is out
of bounds" and "index cannot be negative number" would help, surely).
--
Best regards,
Nikolay
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
