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_node.c

Blame
    • 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.