Josh Berkus <josh@agliodbs.com> 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().
>
> 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. 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.
>
> Or is there some concept I'm missing?
I would certainly second that. Consider all that making it NULL breaks:
length(a) != array_upper(a)-array_lower(a)
array_upper(a||b) == array_upper(a)+length(b)
If someone implements pop and push it sure makes things weird that push
doesn't always increment the length pop doesn't decrement the length until 0.
Perhaps you're worried that you have pick an arbitrary lower and upper bound
and, strangely, that the upper bound would actually be one less than the lower
bound such as [1,0]. However this isn't really any different than the normal
case. All arrays in postgres have arbitrary lower bounds.
Fwiw, the int_aggregate function from int_aggregate.c in the contrib section
makes arrays that don't violate these invariants. For empty arrays the
dimensions are [0,-1].
This isn't hypothetical for me. Whenever I end up replacing int_aggregate with
a standard function that constructs your style arrays my app would break. I
guess I'll have to add a coalesce(...,0) to my array_length() function to work
around it. Which only seems like strong evidence it's the wrong behaviour.
--
greg