1. 16 Jun, 2020 3 commits
  2. 15 Jun, 2020 8 commits
  3. 14 Jun, 2020 3 commits
    • Tom Lane's avatar
      Fix behavior of exp() and power() for infinity inputs. · decbe2bf
      Tom Lane authored
      Previously, these functions tended to throw underflow errors for
      negative-infinity exponents.  The correct thing per POSIX is to
      return 0, so let's do that instead.  (Note that the SQL standard
      is silent on such issues, as it lacks the concepts of either Inf
      or NaN; so our practice is to follow POSIX whenever a corresponding
      C-library function exists.)
      
      Also, add a bunch of test cases verifying that exp() and power()
      actually do follow POSIX for Inf and NaN inputs.  While this patch
      should guarantee that exp() passes the tests, power() will not unless
      the platform's pow(3) is fully POSIX-compliant.  I already know that
      gaur fails some of the tests, and I am suspicious that the Windows
      animals will too; the extent of compliance of other old platforms
      remains to be seen.  We might choose to drop failing test cases, or
      to work harder at overriding pow(3) for these cases, but first let's
      see just how good or bad the situation is.
      
      Discussion: https://postgr.es/m/582552.1591917752@sss.pgh.pa.us
      decbe2bf
    • Peter Eisentraut's avatar
      Add test coverage for EXTRACT() · 378badc8
      Peter Eisentraut authored
      The variants for time and timetz had zero test coverage, the variant
      for interval only very little.  This adds practically full coverage
      for those functions.
      Reviewed-by: default avatarVik Fearing <vik@postgresfriends.org>
      Reviewed-by: default avatarTom Lane <tgl@sss.pgh.pa.us>
      Discussion: https://www.postgresql.org/message-id/flat/c3306ac7-fcae-a1b8-1e30-6a379d605bcb%402ndquadrant.com
      378badc8
    • Michael Paquier's avatar
      Replace superuser check by ACLs for replication origin functions · cc072641
      Michael Paquier authored
      This patch removes the hardcoded check for superuser privileges when
      executing replication origin functions.  Instead, execution is revoked
      from public, meaning that those functions can be executed by a superuser
      and that access to them can be granted.
      
      Author: Martín Marqués
      Reviewed-by: Kyotaro Horiguchi, Michael Paquier, Masahiko Sawada
      Discussion: https:/postgr.es/m/CAPdiE1xJMZOKQL3dgHMUrPqysZkgwzSMXETfKkHYnBAB7-0VRQ@mail.gmail.com
      cc072641
  4. 13 Jun, 2020 8 commits
  5. 12 Jun, 2020 4 commits
    • David Rowley's avatar
      Add missing extern keyword for a couple of numutils functions · 9a7fccd9
      David Rowley authored
      In passing, also remove a few surplus empty lines from pg_ltoa and
      pg_ulltoa_n in numutils.c
      
      Reported-by: Andrew Gierth
      Discussion: https://postgr.es/m/87y2ou3xuh.fsf@news-spur.riddles.org.uk
      Backpatch-through: 13, where these changes were introduced
      9a7fccd9
    • Tom Lane's avatar
      Avoid using a cursor in plpgsql's RETURN QUERY statement. · 2f48ede0
      Tom Lane authored
      plpgsql has always executed the query given in a RETURN QUERY command
      by opening it as a cursor and then fetching a few rows at a time,
      which it turns around and dumps into the function's result tuplestore.
      The point of this was to keep from blowing out memory with an oversized
      SPITupleTable result (note that while a tuplestore can spill tuples
      to disk, SPITupleTable cannot).  However, it's rather inefficient, both
      because of extra data copying and because of executor entry/exit
      overhead.  In recent versions, a new performance problem has emerged:
      use of a cursor prevents use of a parallel plan for the executed query.
      
      We can improve matters by skipping use of a cursor and having the
      executor push result tuples directly into the function's result
      tuplestore.  However, a moderate amount of new infrastructure is needed
      to make that idea work:
      
      * We can use the existing tstoreReceiver.c DestReceiver code to funnel
      executor output to the tuplestore, but it has to be extended to support
      plpgsql's requirement for possibly applying a tuple conversion map.
      
      * SPI needs to be extended to allow use of a caller-supplied
      DestReceiver instead of its usual receiver that puts tuples into
      a SPITupleTable.  Two new API calls are needed to handle both the
      RETURN QUERY and RETURN QUERY EXECUTE cases.
      
      I also felt that I didn't want these new API calls to use the legacy
      method of specifying query parameter values with "char" null flags
      (the old ' '/'n' convention); rather they should accept ParamListInfo
      objects containing the parameter type and value info.  This required
      a bit of additional new infrastructure since we didn't yet have any
      parse analysis callback that would interpret $N parameter symbols
      according to type data supplied in a ParamListInfo.  There seems to be
      no harm in letting makeParamList install that callback by default,
      rather than leaving a new ParamListInfo's parserSetup hook as NULL.
      (Indeed, as of HEAD, I couldn't find anyplace that was using the
      parserSetup field at all; plpgsql was using parserSetupArg for its
      own purposes, but parserSetup seemed to be write-only.)
      
      We can actually get plpgsql out of the business of using legacy null
      flags altogether, and using ParamListInfo instead of its ad-hoc
      PreparedParamsData structure; but this requires inventing one more
      SPI API call that can replace SPI_cursor_open_with_args.  That seems
      worth doing, though.
      
      SPI_execute_with_args and SPI_cursor_open_with_args are now unused
      anywhere in the core PG distribution.  Perhaps someday we could
      deprecate/remove them.  But cleaning up the crufty bits of the SPI
      API is a task for a different patch.
      
      Per bug #16040 from Jeremy Smith.  This is unfortunately too invasive to
      consider back-patching.  Patch by me; thanks to Hamid Akhtar for review.
      
      Discussion: https://postgr.es/m/16040-eaacad11fecfb198@postgresql.org
      2f48ede0
    • Michael Paquier's avatar
      aaf8c990
    • Peter Eisentraut's avatar
      Make more use of RELKIND_HAS_STORAGE() · ffd25822
      Peter Eisentraut authored
      Make use of RELKIND_HAS_STORAGE() where appropriate, instead of
      listing out the relkinds individually.  No behavior change intended.
      Reviewed-by: default avatarTom Lane <tgl@sss.pgh.pa.us>
      Discussion: https://www.postgresql.org/message-id/flat/7a22bf51-2480-d999-1794-191ba67ff47c%402ndquadrant.com
      ffd25822
  6. 11 Jun, 2020 12 commits
  7. 10 Jun, 2020 2 commits