pgsql: Fix array slicing of int2vector and oidvector values.
От | Tom Lane |
---|---|
Тема | pgsql: Fix array slicing of int2vector and oidvector values. |
Дата | |
Msg-id | E1VkO7t-0001fr-Ac@gemulon.postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
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. Branch ------ REL9_3_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/c4d3cd3dc8514147cc8d30a648e4970a2a876ca8 Modified Files -------------- src/backend/parser/parse_node.c | 13 +++++++++++++ src/backend/parser/parse_target.c | 8 +++++--- src/include/catalog/pg_type.h | 2 ++ 3 files changed, 20 insertions(+), 3 deletions(-)
В списке pgsql-committers по дате отправления: