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

int8.h

Blame
    • Tom Lane's avatar
      5f7c2bdb
      sum() on int2 and int4 columns now uses an int8, not numeric, accumulator · 5f7c2bdb
      Tom Lane authored
      for speed reasons; its result type also changes to int8.  avg() on these
      datatypes now accumulates the running sum in int8 for speed; but we still
      deliver the final result as numeric, so that fractional accuracy is
      preserved.
      
      count() now counts and returns in int8, not int4.  I am a little nervous
      about this possibly breaking users' code, but there didn't seem to be
      a strong sentiment for avoiding the problem.  If we get complaints during
      beta, we can change count back to int4 and add a "count8" aggregate.
      For that matter, users can do it for themselves with a simple CREATE
      AGGREGATE command; the int4inc function is still present, so no C hacking
      is needed.
      
      Also added max() and min() aggregates for OID that do proper unsigned
      comparison, instead of piggybacking on int4 aggregates.
      
      initdb forced.
      5f7c2bdb
      History
      sum() on int2 and int4 columns now uses an int8, not numeric, accumulator
      Tom Lane authored
      for speed reasons; its result type also changes to int8.  avg() on these
      datatypes now accumulates the running sum in int8 for speed; but we still
      deliver the final result as numeric, so that fractional accuracy is
      preserved.
      
      count() now counts and returns in int8, not int4.  I am a little nervous
      about this possibly breaking users' code, but there didn't seem to be
      a strong sentiment for avoiding the problem.  If we get complaints during
      beta, we can change count back to int4 and add a "count8" aggregate.
      For that matter, users can do it for themselves with a simple CREATE
      AGGREGATE command; the int4inc function is still present, so no C hacking
      is needed.
      
      Also added max() and min() aggregates for OID that do proper unsigned
      comparison, instead of piggybacking on int4 aggregates.
      
      initdb forced.