Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 29 Jul, 2018 5 commits
  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 1 commit