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

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

> ... My hope was that eventually anyarray I/O functions 
> could eliminate the need to create an array type for every data type you 
> wanted to use as an array element.

Interesting thought, but then how do you declare the type of an array
column, or the type of a function argument that's not supposed to range
over every array type?  If we can't use an OID to identify a data type
completely, we're going to have lots of problems.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: Some array semantics issues
Next
From: Tom Lane
Date:
Subject: Re: PANIC: could not locate a valid checkpoint record