Re: Some array semantics issues

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Joe Conway <mail(at)joeconway(dot)com> writes:
> > First, the spec only allows arrays to have a lower bound of 1. That
> > requirement simplifies a whole lot of things. I don't think that many
> > people actually depend on other than 1 as a lower bound (or at least if
> > they do, they weren't dumping and reloading those databases prior to
> > 8.0) -- maybe given other possibly non-backward compatible changes for
> > NULLs, we should also change this?
>
> I don't have a lot of use for arguments that go "we should remove any
> functionality that's not in the spec" ... ISTM that variable lower
> bounds are clearly useful for some applications, and even if they had
> bugs in earlier releases that's not an argument for removing them.

Normally I don't either. But it's not just functionality that's not in the
spec. It's functionality that creates behaviour the spec specifies otherwise.

That is, if you have an array [1,2] the spec says you can get 1 by referring
to arr[1]. On Postgres you have to take more care. There could easily be code
out there that won't work on Postgres because of this difference.

The main reason for having non-zero lower bounds in the first place was
originally that NULLs weren't allowed in arrays. Otherwise you run into
problems when you try to set arr[5] = 1 when there isn't an arr[1]..arr[4].
But if we have NULLs in arrays then we could easily have all arrays have lower
bounds of 1. We don't even have to store the leading NULL elements.

I think having all arrays start at 1 would actually much simplify the
semantics and avoid a lot of strange corner cases and surprising behaviour
that will follow from having non-1 based arrays.

--
greg