Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 29 Jul, 2018 4 commits
    • Michael Paquier's avatar
      Fix two oversights from 9ebe0572 which refactored cluster_rel · 9f7ba88a
      Michael Paquier authored 
      The recheck option became a no-op as ClusterOption failed to set proper
values for each element.  There was a second code path where local
options got overwritten.

Both issues have been spotted by Coverity.
      9f7ba88a
    • Noah Misch's avatar
      Document security implications of qualified names. · e09144e6
      Noah Misch authored 
      Commit 5770172c documented secure schema
usage, and that advice suffices for using unqualified names securely.
Document, in typeconv-func primarily, the additional issues that arise
with qualified names.  Back-patch to 9.3 (all supported versions).

Reviewed by Jonathan S. Katz.

Discussion: https://postgr.es/m/20180721012446.GA1840594@rfd.leadboat.com
      e09144e6
    • Tomas Vondra's avatar
      Provide separate header file for built-in float types · 6bf0bc84
      Tomas Vondra authored 
      Some data types under adt/ have separate header files, but most simple
ones do not, and their public functions are defined in builtins.h.  As
the patches improving geometric types will require making additional
functions public, this seems like a good opportunity to create a header
for floats types.

Commit 1acf7572 made _cmp functions public to solve NaN issues locally
for GiST indexes.  This patch reworks it in favour of a more widely
applicable API.  The API uses inline functions, as they are easier to
use compared to macros, and avoid double-evaluation hazards.

Author: Emre Hasegeli
Reviewed-by: Kyotaro Horiguchi

Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
      6bf0bc84
    • 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
  3. 28 Jul, 2018 5 commits
  5. 27 Jul, 2018 5 commits
  7. 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
  9. 25 Jul, 2018 2 commits
  11. 24 Jul, 2018 8 commits
  13. 23 Jul, 2018 8 commits
  15. 22 Jul, 2018 2 commits
  17. 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
  19. 20 Jul, 2018 2 commits