pgsql: Remove support for Python older than 2.6
Remove support for Python older than 2.6 Supporting very old Python versions is a maintenance burden, especially with the several variant test files to maintain for Python <2.6. Since we have dropped support for older OpenSSL versions in 7b283d0e1d1d79bf1c962d790c94d2a53f3bb38a, RHEL 5 is now effectively desupported, and that was also the only mainstream operating system still using Python versions before 2.6, so it's a good time to drop those as well. Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/flat/98b69261-298c-13d2-f34d-836fd9c29b21%402ndquadrant.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/37f21ed132d1c5aee88e81fee0a0b7e735673d35 Modified Files -- config/python.m4 | 4 +- configure | 4 +- doc/src/sgml/installation.sgml | 2 +- doc/src/sgml/plpython.sgml | 16 +- src/pl/plpython/expected/README| 4 - src/pl/plpython/expected/plpython_error_0.out | 447 .../plpython/expected/plpython_subtransaction.out | 65 --- .../expected/plpython_subtransaction_0.out | 448 - .../expected/plpython_subtransaction_5.out | 448 - src/pl/plpython/plpy_elog.c| 6 - src/pl/plpython/plpython.h | 29 -- src/pl/plpython/sql/plpython_subtransaction.sql| 37 -- 12 files changed, 7 insertions(+), 1503 deletions(-)
pgsql: Modernize Python exception syntax in tests
Modernize Python exception syntax in tests Change the exception syntax used in the tests to use the more current except Exception as ex: rather than the old except Exception, ex: Since support for Python <2.6 has been removed, all supported versions now support the new style, and we can save one step in the Python 3 compatibility conversion. Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/flat/98b69261-298c-13d2-f34d-836fd9c29b21%402ndquadrant.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/45223fd9cefe483daa4af7740f15c004486636eb Modified Files -- src/pl/plpython/expected/plpython_ereport.out| 4 ++-- src/pl/plpython/expected/plpython_error.out | 8 src/pl/plpython/expected/plpython_import.out | 2 +- src/pl/plpython/expected/plpython_params.out | 2 +- src/pl/plpython/expected/plpython_spi.out| 6 +++--- src/pl/plpython/expected/plpython_subtransaction.out | 2 +- src/pl/plpython/expected/plpython_types.out | 2 +- src/pl/plpython/regress-python3-mangle.mk| 2 +- src/pl/plpython/sql/plpython_ereport.sql | 4 ++-- src/pl/plpython/sql/plpython_error.sql | 8 src/pl/plpython/sql/plpython_import.sql | 2 +- src/pl/plpython/sql/plpython_params.sql | 2 +- src/pl/plpython/sql/plpython_spi.sql | 6 +++--- src/pl/plpython/sql/plpython_subtransaction.sql | 2 +- src/pl/plpython/sql/plpython_types.sql | 2 +- src/tools/msvc/vcregress.pl | 1 - 16 files changed, 27 insertions(+), 28 deletions(-)
pgsql: Reimplement nullification of walsender timestamp
Reimplement nullification of walsender timestamp Make the value null only at pg_stat_activity-output time, as suggested by Tom Lane, instead of messing with the internal state. This should appease buildfarm members with force_parallel_mode=regress, which are running parallel queries on logical replication walsenders. The fact that walsenders can run parallel queries should perhaps be studied more carefully, but for the moment let's get rid of the red blots in buildfarm. Backpatch to pg10, like the previous commit. Discussion: https://postgr.es/m/30804.1578438...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f5d28710c707ad602cd869602e092cc9d538cbb9 Modified Files -- src/backend/access/transam/xact.c | 7 --- src/backend/utils/adt/pgstatfuncs.c | 8 +++- 2 files changed, 7 insertions(+), 8 deletions(-)
pgsql: Reimplement nullification of walsender timestamp
Reimplement nullification of walsender timestamp Make the value null only at pg_stat_activity-output time, as suggested by Tom Lane, instead of messing with the internal state. This should appease buildfarm members with force_parallel_mode=regress, which are running parallel queries on logical replication walsenders. The fact that walsenders can run parallel queries should perhaps be studied more carefully, but for the moment let's get rid of the red blots in buildfarm. Backpatch to pg10, like the previous commit. Discussion: https://postgr.es/m/30804.1578438...@sss.pgh.pa.us Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/da42b9f3ff4375972e535368e875ca0dbbdf322a Modified Files -- src/backend/access/transam/xact.c | 7 --- src/backend/utils/adt/pgstatfuncs.c | 8 +++- 2 files changed, 7 insertions(+), 8 deletions(-)
pgsql: Reimplement nullification of walsender timestamp
Reimplement nullification of walsender timestamp Make the value null only at pg_stat_activity-output time, as suggested by Tom Lane, instead of messing with the internal state. This should appease buildfarm members with force_parallel_mode=regress, which are running parallel queries on logical replication walsenders. The fact that walsenders can run parallel queries should perhaps be studied more carefully, but for the moment let's get rid of the red blots in buildfarm. Backpatch to pg10, like the previous commit. Discussion: https://postgr.es/m/30804.1578438...@sss.pgh.pa.us Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/20c4df8c8d7c54e34e921e770b594582d276f19e Modified Files -- src/backend/access/transam/xact.c | 7 --- src/backend/utils/adt/pgstatfuncs.c | 8 +++- 2 files changed, 7 insertions(+), 8 deletions(-)
pgsql: Reimplement nullification of walsender timestamp
Reimplement nullification of walsender timestamp Make the value null only at pg_stat_activity-output time, as suggested by Tom Lane, instead of messing with the internal state. This should appease buildfarm members with force_parallel_mode=regress, which are running parallel queries on logical replication walsenders. The fact that walsenders can run parallel queries should perhaps be studied more carefully, but for the moment let's get rid of the red blots in buildfarm. Backpatch to pg10, like the previous commit. Discussion: https://postgr.es/m/30804.1578438...@sss.pgh.pa.us Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/af43581e8b297b2527e0b1716b616b7ea1fc496f Modified Files -- src/backend/access/transam/xact.c | 7 --- src/backend/utils/adt/pgstatfuncs.c | 8 +++- 2 files changed, 7 insertions(+), 8 deletions(-)
pgsql: Improve the handling of result type coercions in SQL functions.
Improve the handling of result type coercions in SQL functions. Use the parser's standard type coercion machinery to convert the output column(s) of a SQL function's final SELECT or RETURNING to the type(s) they should have according to the function's declared result type. We'll allow any case where an assignment-level coercion is available. Previously, we failed unless the required coercion was a binary-compatible one (and the documentation ignored this, falsely claiming that the types must match exactly). Notably, the coercion now accounts for typmods, so that cases where a SQL function is declared to return a composite type whose columns are typmod-constrained now behave as one would expect. Arguably this aspect is a bug fix, but the overall behavioral change here seems too large to consider back-patching. A nice side-effect is that functions can now be inlined in a few cases where we previously failed to do so because of type mismatches. Discussion: https://postgr.es/m/18929.1574895...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/913bbd88dc6b859c70ebb48107b38d693c4c6673 Modified Files -- doc/src/sgml/xfunc.sgml | 44 ++- src/backend/catalog/pg_proc.c| 11 +- src/backend/executor/functions.c | 508 ++- src/backend/optimizer/util/clauses.c | 131 +++- src/include/executor/functions.h | 8 +- src/test/regress/expected/rangefuncs.out | 210 - src/test/regress/sql/rangefuncs.sql | 76 - 7 files changed, 656 insertions(+), 332 deletions(-)
pgsql: Improve GSSAPI Encryption startup comment in libpq
Improve GSSAPI Encryption startup comment in libpq The original comment was a bit confusing, pointed out by Alvaro Herrera. Thread: https://postgr.es/m/20191224151520.GA16435%40alvherre.pgsql Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8dd1511e39acd729020e151deb15a958300ebff5 Modified Files -- src/interfaces/libpq/fe-connect.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)
pgsql: Fix handling of generated columns in ALTER TABLE.
Fix handling of generated columns in ALTER TABLE. ALTER TABLE failed if a column referenced in a GENERATED expression had been added or changed in type earlier in the ALTER command. That's because the GENERATED expression needs to be evaluated against the table's updated tuples, but it was being evaluated against the original tuples. (Fortunately the executor has adequate cross-checks to notice the mismatch, so we just got an obscure error message and not anything more dangerous.) Per report from Andreas Joseph Krogh. Back-patch to v12 where GENERATED was added. Discussion: https://postgr.es/m/VisenaEmail.200.231b0a41523275d0.16ea7f800c7@tc7-visena Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c24f3b70efc243bb44a6a4121032f19e2d6e813e Modified Files -- src/backend/commands/tablecmds.c| 33 ++- src/test/regress/expected/generated.out | 97 ++--- src/test/regress/sql/generated.sql | 31 +-- 3 files changed, 132 insertions(+), 29 deletions(-)
pgsql: Fix handling of generated columns in ALTER TABLE.
Fix handling of generated columns in ALTER TABLE. ALTER TABLE failed if a column referenced in a GENERATED expression had been added or changed in type earlier in the ALTER command. That's because the GENERATED expression needs to be evaluated against the table's updated tuples, but it was being evaluated against the original tuples. (Fortunately the executor has adequate cross-checks to notice the mismatch, so we just got an obscure error message and not anything more dangerous.) Per report from Andreas Joseph Krogh. Back-patch to v12 where GENERATED was added. Discussion: https://postgr.es/m/VisenaEmail.200.231b0a41523275d0.16ea7f800c7@tc7-visena Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4ac8aaa36fa24639989849c8109f8b52e9544fd1 Modified Files -- src/backend/commands/tablecmds.c| 33 ++- src/test/regress/expected/generated.out | 97 ++--- src/test/regress/sql/generated.sql | 31 +-- 3 files changed, 132 insertions(+), 29 deletions(-)
pgsql: pgbench: Use common logging API
pgbench: Use common logging API Author: Fabien COELHO Reviewed-by: Michael Paquier Reviewed-by: Peter Eisentraut Discussion: https://www.postgresql.org/message-id/flat/alpine.DEB.2.21.1912241100390.3339@pseudo Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/30a3e772b4013d6593e4141cebd5ebfaff4d71a8 Modified Files -- src/bin/pgbench/pgbench.c | 398 - src/bin/pgbench/t/002_pgbench_no_server.pl | 8 +- 2 files changed, 176 insertions(+), 230 deletions(-)
