I have on my todo an item regarding arrays with a dimension lower bound 
of something other than one. The issue is that when stored, dumped, and 
then reloaded, the array lower bound is reset to 1. Example:

create table foo(f1 int[]);
insert into foo values(array[1]);
update foo set f1[-1:0] = array[-1,0];
select f1, array_lower(f1, 1) from foo;
     f1    | array_lower
----------+-------------
  {-1,0,1} |          -1
(1 row)

When the above table is dumped, you get this:

CREATE TABLE foo (
     f1 integer[]
);
COPY foo (f1) FROM stdin;
{-1,0,1}
\.

And when you restore it, you get this:

select f1, array_lower(f1, 1) from foo;
     f1    | array_lower
----------+-------------
  {-1,0,1} |           1
(1 row)

Tom mentioned in an earlier thread that array_in() allowed an array 
string literal to contain dimension information, and indeed it does:

select f1, array_lower(f1, 1) from (select '[0:2]={-1,0,1}'::int[] as 
f1) as ss;
     f1    | array_lower
----------+-------------
  {-1,0,1} |           0
(1 row)

It seems, though, there is a bug in that functionality as it does not 
handle negative array indicies:

select f1, array_lower(f1, 1) from (select '[-1:1]={-1,0,1}'::int[] as 
f1) as ss;
ERROR:  missing dimension value

To make all of this more interesting, we have also in the past discussed 
hardwiring array lower bounds to 1, as that's what SQL99 says it should be.

I could fix the current issue by making array_in accept negative array 
indicies, and modifying pg_dump to emit the dimensional portion of the 
string literals (or perhaps array_out ought to do that whenever lower 
bound != 1?). But if we are likely to change array semantics in some 
future release to hardwire a lower bound of 1, it might be better to not 
fix this at all (i.e. why encourage people to use functionality that 
might disappear in a release or so).

Thoughts/guidance appreciated.

Thanks,

Joe


Tue, 03 Aug 2004 09:51:40 -0700
Joe Conway <mail@joeconway.com>
RFC: arrays with other than 1 as a dimension lower bound