Re: Inconsistent behavior on Array & Is Null?
От | Joe Conway |
---|---|
Тема | Re: Inconsistent behavior on Array & Is Null? |
Дата | |
Msg-id | 406CCFEF.2080203@joeconway.com обсуждение исходный текст |
Ответ на | Re: Inconsistent behavior on Array & Is Null? (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Inconsistent behavior on Array & Is Null?
|
Список | pgsql-hackers |
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 dimensions. It is entirely possible to have a real array that starts at a lower bound of 0 (or even an upper bound of 0). regression=# select f[0] from (select 99 || array[1,2,3] as f) as t; f ---- 99 (1 row) regression=# create table a1 (f int[]); CREATE TABLE regression=# insert into a1 values('{}'); INSERT 18688045 1 regression=# update a1 set f[0] = 99; UPDATE 1 regression=# select array_upper(f,1) from a1; array_upper ------------- 0 (1 row) > The way it works now, array_upper on a NULL array produces the same > results as array_upper on an empty-but-non-null array. 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 change for array_dims at the time array_lower and array_upper were created. I don't really believe they should throw an ERROR on an empty array though. Joe
В списке pgsql-hackers по дате отправления: