Joe Conway [EMAIL PROTECTED] writes:
I'd think given the preceding, it would make more sense to throw an error
whenever trying to access an element greater than the length.
For an analogous situation in SQL I would propose
select (select foo from bar where xyz);
if there are no records in
Joe Conway [EMAIL PROTECTED] writes:
Greg Stark wrote:
This really ought to work, it obviously shouldn't allow you to set a[5] and
then surreptitiously move it to a[1]. But nor should it generate an error,
since I may well have a specific meaning for a[5] and may be planning to fill
in
Greg Stark wrote:
Joe Conway [EMAIL PROTECTED] writes:
I agree. I had always envisioned something exactly like that once we supported
NULL elements. As far as the implementation goes, I think it would be very
similar to tuples -- a null bitmask that would exist if any elements are NULL.
Well you
Greg Stark [EMAIL PROTECTED] writes:
array_lower() and array_upper() are returning NULL for a non-null
input, the empty array, even though lower and upper bounds are known
just as well as they are for any other sized array. They are behaving
as if there's something unknown about the empty
Tom Lane [EMAIL PROTECTED] writes:
Hm. My idea of the index lower bound is the smallest index for which
there is an array member --- so I agree with Joe that it's not very
well defined for an empty array.
Hm. The problem is that they have other implications. Like the upper bound is
one
Greg Stark [EMAIL PROTECTED] writes:
Well that breaks other things. Then lots of functions have to become
non-strict to work properly because they should have valid output when passed
null values. Ick.
...
I'm leaning towards suggesting that postgres should follow sql-99 here and
normalize
Greg Stark wrote:
array_lower() and array_upper() are returning NULL for a non-null input, the
empty array, even though lower and upper bounds are known just as well as they
are for any other sized array. They are behaving as if there's something
unknown about the empty array that makes it hard to
Tom Lane wrote:
I think that maybe we ought to question these two properties:
* empty array is different from NULL ... really? Why?
I think this makes sense, similar to the difference between '' and NULL.
* storing a value into an element of a NULL array yields
a NULL
Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
I'm leaning towards suggesting that postgres should follow sql-99 here and
normalize all array indexes to have a lower bound of 1.
That would break even more things, no?
On the other hand, it'd get rid of the problem that we presently face
with
Greg Stark wrote:
I'm leaning towards suggesting that postgres should follow sql-99 here and
normalize all array indexes to have a lower bound of 1. Then array_lower and
array_upper become entirely unnecessary. Instead we just have array_length
which is exactly equivalent to my idea of
Tom Lane [EMAIL PROTECTED] writes:
That would break even more things, no?
On the other hand, it'd get rid of the problem that we presently face
with dump/restore of arrays that don't have lower bound 1. Because
pg_dump doesn't do anything to mark such values, they'll end up with
lower
Joe Conway [EMAIL PROTECTED] writes:
Greg Stark wrote:
I'm leaning towards suggesting that postgres should follow sql-99 here and
normalize all array indexes to have a lower bound of 1. Then array_lower and
array_upper become entirely unnecessary. Instead we just have array_length
which
Joe Conway [EMAIL PROTECTED] writes:
Greg Stark wrote:
array_lower() and array_upper() are returning NULL for a non-null input, the
empty array, even though lower and upper bounds are known just as well as they
are for any other sized array. They are behaving as if there's something
Greg Stark wrote:
This really ought to work, it obviously shouldn't allow you to set a[5] and
then surreptitiously move it to a[1]. But nor should it generate an error,
since I may well have a specific meaning for a[5] and may be planning to fill
in a[1]..a[4] later.
The logical thing to do, I
Josh Berkus wrote:
I'm noticing some inconsistent behavior regarding empty arrays and IS NULL
status.For example:
net_test=# select array_upper('{}'::INT[], 1) IS NULL;
?column?
--
t
(1 row)
This is correct. There are no dimensions to an empty array by
definition. The only other
Joe,
This is correct. There are no dimensions to an empty array by
definition. The only other way to handle this would be an ERROR. I
followed the lead of (the pre-existing function) array_dims() when
creating array_upper() and array_lower().
What about a 0?That seems more consistent
Josh Berkus wrote:
What about a 0?That seems more consistent to me. If the array
is empty, its dimensions are not NULL, meaning unknown, but in
fact zero elements, which is a known value.
They cannot be 0 because 0 is a real index. They are undefined, because
an empty array has no
Joe,
Sure, and in both cases array_upper is undefined because there are no
array dimensions to speak of. I guess you might argue that array_upper,
array_lower, and array_dims should all produce an ERROR on null input
instead of NULL. But that would have been an un-backward compatible
Josh Berkus [EMAIL PROTECTED] writes:
Joe,
This is correct. There are no dimensions to an empty array by
definition. The only other way to handle this would be an ERROR. I
followed the lead of (the pre-existing function) array_dims() when
creating array_upper() and array_lower().
Greg Stark wrote:
length(a) != array_upper(a)-array_lower(a)
[You really meant array_upper(a) - array_lower(a) + 1 I'd guess]
length(A) is a missing function at the moment; the spec actually calls
it CARDINALITY. Once available, you would use it to determine array
length. SQL2003 says:
The
Joe Conway [EMAIL PROTECTED] writes:
Same here; this would be:
array_upper(a || b) == array_upper(a) + CARDINALITY(b)
and would work just fine. Note that if array-a is NULL, then the spec defines a
|| b as NULL. See section 6.35:
Why are you talking about when a is NULL? The original
Greg Stark wrote:
Joe Conway [EMAIL PROTECTED] writes:
Same here; this would be:
array_upper(a || b) == array_upper(a) + CARDINALITY(b)
and would work just fine. Note that if array-a is NULL, then the spec defines a
|| b as NULL. See section 6.35:
Why are you talking about when a is NULL? The
Joe Conway [EMAIL PROTECTED] writes:
You seem to be saying that because the output of certain functions that operate
on empty arrays is NULL, it somehow implies that the array is being treated as
NULL -- that's just plain incorrect.
Not incorrect, but a sign something weird is going on. It
Joe,
First off, pardon me if these are known things which are already fixed in CVS.
Also, let me again thank you for all the work on Arrays in 7.4; I've been
able to tremendously simplify quite a number of procedures in my databases
thanks to the new array support.
Now, the issue:
I'm
24 matches
Mail list logo
