Re: Some array semantics issues - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Some array semantics issues
Date
Msg-id 437BD705.7040501@joeconway.com
Whole thread Raw
In response to Re: Some array semantics issues  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>>Joe Conway <mail@joeconway.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.

This is an important point. SQL2003 doesn't leave this as undefined:

4.10.2 Arrays
An array is a collection A in which each element is associated with 
exactly one ordinal position in A. If n is the cardinality of A, then 
the ordinal position p of an element is an integer in the range 1 (one) 
<= p <= n. If EDT is the element type of A, then A can thus be 
considered as a function of the integers in the range 1 (one) to n into EDT.

Joe


pgsql-hackers by date:

Previous
From: Dave Cramer
Date:
Subject: Re: PANIC: could not locate a valid checkpoint record
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: [COMMITTERS] pgsql: make_restrictinfo() failed to attach