Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

parse_target.c

  • Tom Lane's avatar
    45e02e32
    Fix array slicing of int2vector and oidvector values. · 45e02e32
    Tom Lane authored
    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.
    45e02e32
    History
    Fix array slicing of int2vector and oidvector values.
    Tom Lane authored
    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.