Re: Inconsistent behavior on Array & Is Null?
От | Joe Conway |
---|---|
Тема | Re: Inconsistent behavior on Array & Is Null? |
Дата | |
Msg-id | 406D91C3.7060204@joeconway.com обсуждение исходный текст |
Ответ на | Re: Inconsistent behavior on Array & Is Null? (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: Inconsistent behavior on Array & Is Null?
|
Список | pgsql-hackers |
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 provide a lower bound or > upper bound. Sorry, but I still disagree. There *is* something unknown about the lower and upper bound of an empty array because there are no bounds. > I know it's possible to work around this special case, but I'm saying it's odd > to have an irregularity in the interface. What justification is there for > breaking the invariant length = upper-lower+1 ? I don't see the spec defined CARDINALITY as a workaround. It defines length as the number of elements in the array. When the array is empty, that value is clearly 0. Nothing strange about it. > Yes I read the examples you gave, but you a) had to work around the nit with a > special case in your function and b) still have corner cases where one of the > invariants I named fails, namely: > test=# select array_upper(a||b, 1), array_upper(a,1)+array_length(b) from (select '{}'::int[] as a, array[1,2] as b) asx; > array_upper | ?column? > -------------+---------- > 2 | > (1 row) OK, you got me with this corner case. But using what you described as the result int_aggregate would give you in this case (-1), you would get an even stranger answer (-1 + 2 = 1) that would still need to be worked around. Joe
В списке pgsql-hackers по дате отправления: