Greg Stark <gsstark@mit.edu> writes:
> What I'm curious about is where the original behaviour came from. Is
> it just because insert with subscripts was never implemented? Or was
> there a rationale for ignoring the subscripts?
It's been awhile, but I think that "ignore the subscripts" may have been
something I put in, because the original behavior was even more broken.
Old-timers will recall that the array behavior we got from Berkeley was
bizarrely broken in a whole lot of ways :-(
The regression tests expect that this will work:
INSERT INTO arrtest (a, b[1][2][2], c, d[2][1]) VALUES ('{}', '{3,4}', '{foo,bar}', '{bar,foo}');
(AFAICT this has been in there since Berkeley) and you'll notice that
the values supplied for b and d do not agree at all with the
dimensionality specified by the insert targetlist. There are several
other errors of the same kind. So the net effect has certainly always
been that subscripts supplied here were ignored.
Given that we never documented that you could write a subscript in
INSERT, I doubt anybody ever tried, so the lack of functionality didn't
get noticed.
With the patch I'm about to commit, the subscripts *are* functional
and so the above command draws an error. I've updated the regression
tests to do
INSERT INTO arrtest (a, b[1:2], c, d[1:2]) VALUES ('{}', '{3,4}', '{foo,bar}', '{bar,foo}');
which inserts the same data that this test has always inserted.
Note that you have to write array-slice subscripts if your intention is
to insert more than one element this way. It appears that the Berkeley
guys may have intended to allow this shorthand as an equivalent to the
above:
INSERT INTO arrtest (a, b[2], c, d[2]) VALUES ('{}', '{3,4}', '{foo,bar}', '{bar,foo}');
but I think that's a lousy idea since it forecloses assigning just a
single array element, which seems like behavior at least as useful
as the slice case. With the patch, you can do this:
INSERT INTO arrtest (b[1], b[2]) VALUES (3, 4);
to insert the same b array value as the above.
regards, tom lane