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
