1. 29 Jul, 2018 1 commit
    • Tomas Vondra's avatar
      Refactor geometric functions and operators · a7dc63d9
      Tomas Vondra authored
      The primary goal of this patch is to eliminate duplicate code and share
      code between different geometric data types more often, to prepare the
      ground for additional patches.  Until now the code reuse was limited,
      probably because the simpler types (line and point) were implemented
      after the more complex ones.
      
      The changes are quite extensive and can be summarised as:
      
      * Eliminate SQL-level function calls.
      * Re-use more functions to implement others.
      * Unify internal function names and signatures.
      * Remove private functions from geo_decls.h.
      * Replace should-not-happen checks with assertions.
      * Add comments describe for various functions.
      * Remove some unreachable code.
      * Define delimiter symbols of line datatype like the other ones.
      * Remove the GEODEBUG macro and printf() calls.
      * Unify code style of a few oddly formatted lines.
      
      While the goal was to cause minimal user-visible changes, it was not
      possible to keep the original behavior in all cases - for example when
      handling NaN values, or when reusing code makes the functions return
      consistent results.
      
      Author: Emre Hasegeli
      Reviewed-by: Kyotaro Horiguchi, me
      
      Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
      a7dc63d9
  2. 28 Jul, 2018 5 commits
  3. 27 Jul, 2018 5 commits
  4. 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
  5. 25 Jul, 2018 2 commits
  6. 24 Jul, 2018 8 commits
  7. 23 Jul, 2018 8 commits
  8. 22 Jul, 2018 2 commits
  9. 21 Jul, 2018 2 commits
    • Tom Lane's avatar
      Further portability hacking in pg_upgrade's test script. · 04269320
      Tom Lane authored
      I blew the dust off a Bourne shell (file date 1996, yea verily) and
      tried to run test.sh with it.  It mostly worked, but I found that the
      temp-directory creation code introduced by commit be76a6d3 was not
      compatible, for a couple of reasons: this shell thinks "set -e" should
      force an exit if a command within backticks fails, and it also thinks code
      within braces should be executed by a sub-shell, meaning that variable
      settings don't propagate back up to the parent shell.  In view of Victor
      Wagner's report that Solaris is still using pre-POSIX shells, seems like
      we oughta make this case work.  It's not like the code is any less
      idiomatic this way; the prior coding technique appeared nowhere else.
      
      (There is a remaining bash-ism here, which is that $RANDOM doesn't do
      what the code hopes in non-bash shells.  But the use of $$ elsewhere in
      that path should be enough to ensure uniqueness and some amount of
      randomness, so I think it's okay as-is.)
      
      Back-patch to all supported branches, as the previous commit was.
      
      Discussion: https://postgr.es/m/20180720153820.69e9ae6c@fafnir.local.vm
      04269320
    • Tom Lane's avatar
      Be more paranoid about quoting in pg_upgrade's test script. · 0c0908d9
      Tom Lane authored
      Double-quote $PGDATA in "find" commands introduced by commit da9b580d,
      in case that path contains spaces or other special characters.
      
      Adjust a few other places so that quoting is done more consistently.
      None of the others are actual bugs AFAICS, but it's confusing to readers
      if the same thing is done differently in different places.
      
      Noted by Tels.
      
      Discussion: https://postgr.es/m/c96303c04c360bbedaa04f90f515745b.squirrel@sm.webmail.pair.com
      0c0908d9
  10. 20 Jul, 2018 3 commits
  11. 19 Jul, 2018 2 commits
    • Michael Paquier's avatar
      Add toast tables to most system catalogs · 96cdeae0
      Michael Paquier authored
      It has been project policy to create toast tables only for those catalogs
      that might reasonably need one.  Since this judgment call can change over
      time, just create one for every catalog, as this can be useful when
      creating rather-long entries in catalogs, with recent examples being in
      the shape of policy expressions or customly-formatted SCRAM verifiers.
      
      To prevent circular dependencies and to avoid adding complexity to VACUUM
      FULL logic, exclude pg_class, pg_attribute, and pg_index.  Also, to
      prevent pg_upgrade from seeing a non-empty new cluster, exclude
      pg_largeobject and pg_largeobject_metadata from the set as large object
      data is handled as user data.  Those relations have no reason to use a
      toast table anyway.
      
      Author: Joe Conway, John Naylor
      Reviewed-by: Michael Paquier, Tom Lane
      Discussion: https://postgr.es/m/84ddff04-f122-784b-b6c5-3536804495f8@joeconway.com
      96cdeae0
    • Tom Lane's avatar
      Remove undocumented restriction against duplicate partition key columns. · 24097167
      Tom Lane authored
      transformPartitionSpec rejected duplicate simple partition columns
      (e.g., "PARTITION BY RANGE (x,x)") but paid no attention to expression
      columns, resulting in inconsistent behavior.  Worse, cases like
      "PARTITION BY RANGE (x,(x))") were accepted but would then result in
      dump/reload failures, since the expression (x) would get simplified
      to a plain column later.
      
      There seems no better reason for this restriction than there was for
      the one against duplicate included index columns (cf commit 701fd0bb),
      so let's just remove it.
      
      Back-patch to v10 where this code was added.
      
      Report and patch by Yugo Nagata.
      
      Discussion: https://postgr.es/m/20180712165939.36b12aff.nagata@sraoss.co.jp
      24097167