Tom Lane <[EMAIL PROTECTED]> writes: > Joe Conway <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org