RFC: arrays with other than 1 as a dimension lower bound - Mailing list pgsql-hackers

From Joe Conway
Subject RFC: arrays with other than 1 as a dimension lower bound
Date
Msg-id 410FC29C.8000009@joeconway.com
Whole thread Raw
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Gaetano Mendola
Date:
Subject: CVS comment
Next
From: Joe Conway
Date:
Subject: Re: pgxs: build infrastructure for extensions v4