1. 30 Jul, 2018 1 commit
  2. 29 Jul, 2018 8 commits
  3. 28 Jul, 2018 5 commits
  4. 27 Jul, 2018 5 commits
  5. 26 Jul, 2018 2 commits
    • Tom Lane's avatar
      Provide plpgsql tests for cases involving record field changes. · 9f77ad26
      Tom Lane authored
      We suppressed one of these test cases in commit feb1cc55 because
      it was failing to produce the expected results on CLOBBER_CACHE_ALWAYS
      buildfarm members.  But now we need another test with similar behavior,
      so let's set up a test file that is expected to vary between regular and
      CLOBBER_CACHE_ALWAYS cases, and provide variant expected files.
      
      Someday we should fix plpgsql's failure for change-of-field-type, and
      then the discrepancy will go away and we can fold these tests back
      into plpgsql_record.sql.  But today is not that day.
      
      Discussion: https://postgr.es/m/87wotkfju1.fsf@news-spur.riddles.org.uk
      9f77ad26
    • Tom Lane's avatar
      Avoid crash in eval_const_expressions if a Param's type changes. · 662d12ae
      Tom Lane authored
      Since commit 6719b238 it's been possible for the values of plpgsql
      record field variables to be exposed to the planner as Params.
      (Before that, plpgsql never supplied values for such variables during
      planning, so that the problematic code wasn't reached.)  Other places
      that touch potentially-type-mutable Params either cope gracefully or
      do runtime-test-and-ereport checks that the type is what they expect.
      But eval_const_expressions() just had an Assert, meaning that it either
      failed the assertion or risked crashes due to using an incompatible
      value.
      
      In this case, rather than throwing an ereport immediately, we can just
      not perform a const-substitution in case of a mismatch.  This seems
      important for the same reason that the Param fetch was speculative:
      we might not actually reach this part of the expression at runtime.
      
      Test case will follow in a separate commit.
      
      Patch by me, pursuant to bug report from Andrew Gierth.
      Back-patch to v11 where the previous commit appeared.
      
      Discussion: https://postgr.es/m/87wotkfju1.fsf@news-spur.riddles.org.uk
      662d12ae
  6. 25 Jul, 2018 2 commits
  7. 24 Jul, 2018 8 commits
  8. 23 Jul, 2018 8 commits
  9. 22 Jul, 2018 1 commit
    • Andres Freund's avatar
      Hand code string to integer conversion for performance. · 86eaf208
      Andres Freund authored
      As benchmarks show, using libc's string-to-integer conversion is
      pretty slow. At least part of the reason for that is that strtol[l]
      have to be more generic than what largely is required inside pg.
      
      This patch considerably speeds up int2/int4 input (int8 already was
      already using hand-rolled code).
      
      Most of the existing pg_atoi callers have been converted. But as one
      requires pg_atoi's custom delimiter functionality, and as it seems
      likely that there's external pg_atoi users, it seems sensible to just
      keep pg_atoi around.
      
      Author: Andres Freund
      Reviewed-By: Robert Haas
      Discussion: https://postgr.es/m/20171208214437.qgn6zdltyq5hmjpk@alap3.anarazel.de
      86eaf208