]> granicus.if.org Git - postgresql/commit
Fix array slicing of int2vector and oidvector values.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 24 Nov 2013 01:03:56 +0000 (20:03 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 24 Nov 2013 01:03:56 +0000 (20:03 -0500)
commit45e02e3232ac7cc5ffe36f7986159b5e0b1f6fdc
treebb69dba6e6a73d92b137588928df2204f7c150b6
parentf145454d57bc9dfd105f7236a03a00dd25395dd2
Fix array slicing of int2vector and oidvector values.

The previous coding labeled expressions such as pg_index.indkey[1:3] as
being of int2vector type; which is not right because the subscript bounds
of such a result don't, in general, satisfy the restrictions of int2vector.
To fix, implicitly promote the result of slicing int2vector to int2[],
or oidvector to oid[].  This is similar to what we've done with domains
over arrays, which is a good analogy because these types are very much
like restricted domains of the corresponding regular-array types.

A side-effect is that we now also forbid array-element updates on such
columns, eg while "update pg_index set indkey[4] = 42" would have worked
before if you were superuser (and corrupted your catalogs irretrievably,
no doubt) it's now disallowed.  This seems like a good thing since, again,
some choices of subscripting would've led to results not satisfying the
restrictions of int2vector.  The case of an array-slice update was
rejected before, though with a different error message than you get now.
We could make these cases work in future if we added a cast from int2[]
to int2vector (with a cast function checking the subscript restrictions)
but it seems unlikely that there's any value in that.

Per report from Ronan Dunklau.  Back-patch to all supported branches
because of the crash risks involved.
src/backend/parser/parse_node.c
src/backend/parser/parse_target.c
src/include/catalog/pg_type.h