pgsql: basebackup_to_shell: Add some const qualifiers for consistency
basebackup_to_shell: Add some const qualifiers for consistency Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4cb65e10722164fd12c6b8d010a39ce0f92e71f9 Modified Files -- contrib/basebackup_to_shell/basebackup_to_shell.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Rethink handling of [Prevent|Is]InTransactionBlock in pipeline m
Rethink handling of [Prevent|Is]InTransactionBlock in pipeline mode. Commits f92944137 et al. made IsInTransactionBlock() set the XACT_FLAGS_NEEDIMMEDIATECOMMIT flag before returning "false", on the grounds that that kept its API promises equivalent to those of PreventInTransactionBlock(). This turns out to be a bad idea though, because it allows an ANALYZE in a pipelined series of commands to cause an immediate commit, which is unexpected. Furthermore, if we return "false" then we have another issue, which is that ANALYZE will decide it's allowed to do internal commit-and-start-transaction sequences, thus possibly unexpectedly committing the effects of previous commands in the pipeline. To fix the latter situation, invent another transaction state flag XACT_FLAGS_PIPELINING, which explicitly records the fact that we have executed some extended-protocol command and not yet seen a commit for it. Then, require that flag to not be set before allowing InTransactionBlock() to return "false". Having done that, we can remove its setting of NEEDIMMEDIATECOMMIT without fear of causing problems. This means that the API guarantees of IsInTransactionBlock now diverge from PreventInTransactionBlock, which is mildly annoying, but it seems OK given the very limited usage of IsInTransactionBlock. (In any case, a caller preferring the old behavior could always set NEEDIMMEDIATECOMMIT for itself.) For consistency also require XACT_FLAGS_PIPELINING to not be set in PreventInTransactionBlock. This too is meant to prevent commands such as CREATE DATABASE from silently committing previous commands in a pipeline. Per report from Peter Eisentraut. As before, back-patch to all supported branches (which sadly no longer includes v10). Discussion: https://postgr.es/m/65a899dd-aebc-f667-1d0a-abb89ff3a...@enterprisedb.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f48aa5df4e030ab75bdc2ca5fc480c4a830cf5f3 Modified Files -- doc/src/sgml/protocol.sgml| 9 + src/backend/access/transam/xact.c | 28 ++-- src/backend/tcop/postgres.c | 12 src/include/access/xact.h | 7 +++ 4 files changed, 42 insertions(+), 14 deletions(-)
pgsql: Rethink handling of [Prevent|Is]InTransactionBlock in pipeline m
Rethink handling of [Prevent|Is]InTransactionBlock in pipeline mode. Commits f92944137 et al. made IsInTransactionBlock() set the XACT_FLAGS_NEEDIMMEDIATECOMMIT flag before returning "false", on the grounds that that kept its API promises equivalent to those of PreventInTransactionBlock(). This turns out to be a bad idea though, because it allows an ANALYZE in a pipelined series of commands to cause an immediate commit, which is unexpected. Furthermore, if we return "false" then we have another issue, which is that ANALYZE will decide it's allowed to do internal commit-and-start-transaction sequences, thus possibly unexpectedly committing the effects of previous commands in the pipeline. To fix the latter situation, invent another transaction state flag XACT_FLAGS_PIPELINING, which explicitly records the fact that we have executed some extended-protocol command and not yet seen a commit for it. Then, require that flag to not be set before allowing InTransactionBlock() to return "false". Having done that, we can remove its setting of NEEDIMMEDIATECOMMIT without fear of causing problems. This means that the API guarantees of IsInTransactionBlock now diverge from PreventInTransactionBlock, which is mildly annoying, but it seems OK given the very limited usage of IsInTransactionBlock. (In any case, a caller preferring the old behavior could always set NEEDIMMEDIATECOMMIT for itself.) For consistency also require XACT_FLAGS_PIPELINING to not be set in PreventInTransactionBlock. This too is meant to prevent commands such as CREATE DATABASE from silently committing previous commands in a pipeline. Per report from Peter Eisentraut. As before, back-patch to all supported branches (which sadly no longer includes v10). Discussion: https://postgr.es/m/65a899dd-aebc-f667-1d0a-abb89ff3a...@enterprisedb.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1cca4a75ffb82c7e0497e6195b7fb3ed44dc430e Modified Files -- doc/src/sgml/protocol.sgml| 9 + src/backend/access/transam/xact.c | 28 ++-- src/backend/tcop/postgres.c | 12 src/include/access/xact.h | 7 +++ 4 files changed, 42 insertions(+), 14 deletions(-)
pgsql: Rethink handling of [Prevent|Is]InTransactionBlock in pipeline m
Rethink handling of [Prevent|Is]InTransactionBlock in pipeline mode. Commits f92944137 et al. made IsInTransactionBlock() set the XACT_FLAGS_NEEDIMMEDIATECOMMIT flag before returning "false", on the grounds that that kept its API promises equivalent to those of PreventInTransactionBlock(). This turns out to be a bad idea though, because it allows an ANALYZE in a pipelined series of commands to cause an immediate commit, which is unexpected. Furthermore, if we return "false" then we have another issue, which is that ANALYZE will decide it's allowed to do internal commit-and-start-transaction sequences, thus possibly unexpectedly committing the effects of previous commands in the pipeline. To fix the latter situation, invent another transaction state flag XACT_FLAGS_PIPELINING, which explicitly records the fact that we have executed some extended-protocol command and not yet seen a commit for it. Then, require that flag to not be set before allowing InTransactionBlock() to return "false". Having done that, we can remove its setting of NEEDIMMEDIATECOMMIT without fear of causing problems. This means that the API guarantees of IsInTransactionBlock now diverge from PreventInTransactionBlock, which is mildly annoying, but it seems OK given the very limited usage of IsInTransactionBlock. (In any case, a caller preferring the old behavior could always set NEEDIMMEDIATECOMMIT for itself.) For consistency also require XACT_FLAGS_PIPELINING to not be set in PreventInTransactionBlock. This too is meant to prevent commands such as CREATE DATABASE from silently committing previous commands in a pipeline. Per report from Peter Eisentraut. As before, back-patch to all supported branches (which sadly no longer includes v10). Discussion: https://postgr.es/m/65a899dd-aebc-f667-1d0a-abb89ff3a...@enterprisedb.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ae47f8a9664a65b233ee3c716f3098a5ba71f615 Modified Files -- doc/src/sgml/libpq.sgml | 5 +++-- doc/src/sgml/protocol.sgml| 9 + src/backend/access/transam/xact.c | 28 ++-- src/backend/tcop/postgres.c | 12 src/include/access/xact.h | 7 +++ 5 files changed, 45 insertions(+), 16 deletions(-)
pgsql: Rethink handling of [Prevent|Is]InTransactionBlock in pipeline m
Rethink handling of [Prevent|Is]InTransactionBlock in pipeline mode. Commits f92944137 et al. made IsInTransactionBlock() set the XACT_FLAGS_NEEDIMMEDIATECOMMIT flag before returning "false", on the grounds that that kept its API promises equivalent to those of PreventInTransactionBlock(). This turns out to be a bad idea though, because it allows an ANALYZE in a pipelined series of commands to cause an immediate commit, which is unexpected. Furthermore, if we return "false" then we have another issue, which is that ANALYZE will decide it's allowed to do internal commit-and-start-transaction sequences, thus possibly unexpectedly committing the effects of previous commands in the pipeline. To fix the latter situation, invent another transaction state flag XACT_FLAGS_PIPELINING, which explicitly records the fact that we have executed some extended-protocol command and not yet seen a commit for it. Then, require that flag to not be set before allowing InTransactionBlock() to return "false". Having done that, we can remove its setting of NEEDIMMEDIATECOMMIT without fear of causing problems. This means that the API guarantees of IsInTransactionBlock now diverge from PreventInTransactionBlock, which is mildly annoying, but it seems OK given the very limited usage of IsInTransactionBlock. (In any case, a caller preferring the old behavior could always set NEEDIMMEDIATECOMMIT for itself.) For consistency also require XACT_FLAGS_PIPELINING to not be set in PreventInTransactionBlock. This too is meant to prevent commands such as CREATE DATABASE from silently committing previous commands in a pipeline. Per report from Peter Eisentraut. As before, back-patch to all supported branches (which sadly no longer includes v10). Discussion: https://postgr.es/m/65a899dd-aebc-f667-1d0a-abb89ff3a...@enterprisedb.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/942cc240f95998793e10156952c14961b5559b2a Modified Files -- doc/src/sgml/protocol.sgml| 9 + src/backend/access/transam/xact.c | 28 ++-- src/backend/tcop/postgres.c | 12 src/include/access/xact.h | 7 +++ 4 files changed, 42 insertions(+), 14 deletions(-)
pgsql: Rethink handling of [Prevent|Is]InTransactionBlock in pipeline m
Rethink handling of [Prevent|Is]InTransactionBlock in pipeline mode. Commits f92944137 et al. made IsInTransactionBlock() set the XACT_FLAGS_NEEDIMMEDIATECOMMIT flag before returning "false", on the grounds that that kept its API promises equivalent to those of PreventInTransactionBlock(). This turns out to be a bad idea though, because it allows an ANALYZE in a pipelined series of commands to cause an immediate commit, which is unexpected. Furthermore, if we return "false" then we have another issue, which is that ANALYZE will decide it's allowed to do internal commit-and-start-transaction sequences, thus possibly unexpectedly committing the effects of previous commands in the pipeline. To fix the latter situation, invent another transaction state flag XACT_FLAGS_PIPELINING, which explicitly records the fact that we have executed some extended-protocol command and not yet seen a commit for it. Then, require that flag to not be set before allowing InTransactionBlock() to return "false". Having done that, we can remove its setting of NEEDIMMEDIATECOMMIT without fear of causing problems. This means that the API guarantees of IsInTransactionBlock now diverge from PreventInTransactionBlock, which is mildly annoying, but it seems OK given the very limited usage of IsInTransactionBlock. (In any case, a caller preferring the old behavior could always set NEEDIMMEDIATECOMMIT for itself.) For consistency also require XACT_FLAGS_PIPELINING to not be set in PreventInTransactionBlock. This too is meant to prevent commands such as CREATE DATABASE from silently committing previous commands in a pipeline. Per report from Peter Eisentraut. As before, back-patch to all supported branches (which sadly no longer includes v10). Discussion: https://postgr.es/m/65a899dd-aebc-f667-1d0a-abb89ff3a...@enterprisedb.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/18431ee6f511be0c4cf4d7463899ce318c7632eb Modified Files -- doc/src/sgml/libpq.sgml | 5 +++-- doc/src/sgml/protocol.sgml| 9 + src/backend/access/transam/xact.c | 28 ++-- src/backend/tcop/postgres.c | 12 src/include/access/xact.h | 7 +++ 5 files changed, 45 insertions(+), 16 deletions(-)
pgsql: Rethink handling of [Prevent|Is]InTransactionBlock in pipeline m
Rethink handling of [Prevent|Is]InTransactionBlock in pipeline mode. Commits f92944137 et al. made IsInTransactionBlock() set the XACT_FLAGS_NEEDIMMEDIATECOMMIT flag before returning "false", on the grounds that that kept its API promises equivalent to those of PreventInTransactionBlock(). This turns out to be a bad idea though, because it allows an ANALYZE in a pipelined series of commands to cause an immediate commit, which is unexpected. Furthermore, if we return "false" then we have another issue, which is that ANALYZE will decide it's allowed to do internal commit-and-start-transaction sequences, thus possibly unexpectedly committing the effects of previous commands in the pipeline. To fix the latter situation, invent another transaction state flag XACT_FLAGS_PIPELINING, which explicitly records the fact that we have executed some extended-protocol command and not yet seen a commit for it. Then, require that flag to not be set before allowing InTransactionBlock() to return "false". Having done that, we can remove its setting of NEEDIMMEDIATECOMMIT without fear of causing problems. This means that the API guarantees of IsInTransactionBlock now diverge from PreventInTransactionBlock, which is mildly annoying, but it seems OK given the very limited usage of IsInTransactionBlock. (In any case, a caller preferring the old behavior could always set NEEDIMMEDIATECOMMIT for itself.) For consistency also require XACT_FLAGS_PIPELINING to not be set in PreventInTransactionBlock. This too is meant to prevent commands such as CREATE DATABASE from silently committing previous commands in a pipeline. Per report from Peter Eisentraut. As before, back-patch to all supported branches (which sadly no longer includes v10). Discussion: https://postgr.es/m/65a899dd-aebc-f667-1d0a-abb89ff3a...@enterprisedb.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/20432f8731404d2cef2a155144aca5ab3ae98e95 Modified Files -- doc/src/sgml/libpq.sgml | 5 +++-- doc/src/sgml/protocol.sgml| 9 + src/backend/access/transam/xact.c | 28 ++-- src/backend/tcop/postgres.c | 12 src/include/access/xact.h | 7 +++ 5 files changed, 45 insertions(+), 16 deletions(-)
pgsql: Remove SHA256_HMAC_B from scram-common.h
Remove SHA256_HMAC_B from scram-common.h This referred to the size of the buffers for k_ipad and k_opad in HMAC computations. This is unused since e6bdfd9, where SCRAM has switched to the cryptohash routines for its HMAC calculations rather than its own maths. Reviewed-by: Jacob Champion Discussion: https://postgr.es/m/y5ggmjxhyp0ok...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c6f6646bb0bef315c3836f3f6909c24a985a8621 Modified Files -- src/include/common/scram-common.h | 3 --- 1 file changed, 3 deletions(-)
pgsql: Add grantable MAINTAIN privilege and pg_maintain role.
Add grantable MAINTAIN privilege and pg_maintain role. Allows VACUUM, ANALYZE, REINDEX, REFRESH MATERIALIZED VIEW, CLUSTER, and LOCK TABLE. Effectively reverts 4441fc704d. Instead of creating separate privileges for VACUUM, ANALYZE, and other maintenance commands, group them together under a single MAINTAIN privilege. Author: Nathan Bossart Discussion: https://postgr.es/m/20221212210136.GA449764@nathanxps13 Discussion: https://postgr.es/m/45224.1670476...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/60684dd834a222fefedd49b19d1f0a6189c1632e Modified Files -- doc/src/sgml/ddl.sgml | 42 ++ doc/src/sgml/func.sgml | 3 +- doc/src/sgml/ref/alter_default_privileges.sgml | 4 +- doc/src/sgml/ref/analyze.sgml | 9 +- doc/src/sgml/ref/cluster.sgml | 8 +- doc/src/sgml/ref/grant.sgml | 5 +- doc/src/sgml/ref/lock.sgml | 16 ++- doc/src/sgml/ref/refresh_materialized_view.sgml | 5 +- doc/src/sgml/ref/reindex.sgml | 13 +- doc/src/sgml/ref/revoke.sgml| 2 +- doc/src/sgml/ref/vacuum.sgml| 9 +- doc/src/sgml/user-manag.sgml| 19 ++- src/backend/catalog/aclchk.c| 35 ++--- src/backend/commands/analyze.c | 2 +- src/backend/commands/cluster.c | 18 ++- src/backend/commands/indexcmds.c| 36 +++-- src/backend/commands/lockcmds.c | 3 + src/backend/commands/matview.c | 3 +- src/backend/commands/tablecmds.c| 16 ++- src/backend/commands/vacuum.c | 17 +-- src/backend/parser/gram.y | 7 - src/backend/utils/adt/acl.c | 22 +-- src/bin/pg_dump/dumputils.c | 3 +- src/bin/pg_dump/t/002_pg_dump.pl| 2 +- src/bin/psql/tab-complete.c | 5 +- src/include/catalog/catversion.h| 2 +- src/include/catalog/pg_authid.dat | 9 +- src/include/commands/tablecmds.h| 5 +- src/include/nodes/parsenodes.h | 5 +- src/include/utils/acl.h | 7 +- src/test/regress/expected/dependency.out| 20 +-- src/test/regress/expected/privileges.out| 181 +--- src/test/regress/expected/rowsecurity.out | 32 ++--- src/test/regress/expected/vacuum.out| 6 - src/test/regress/sql/dependency.sql | 2 +- src/test/regress/sql/privileges.sql | 121 36 files changed, 340 insertions(+), 354 deletions(-)
pgsql: Non-decimal integer literals
Non-decimal integer literals Add support for hexadecimal, octal, and binary integer literals: 0x42F 0o273 0b100101 per SQL:202x draft. This adds support in the lexer as well as in the integer type input functions. Reviewed-by: John Naylor Reviewed-by: Zhihong Yu Reviewed-by: David Rowley Reviewed-by: Dean Rasheed Discussion: https://www.postgresql.org/message-id/flat/b239564c-cad0-b23e-c57e-166d883cb...@enterprisedb.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6fcda9aba83449082124825b6d375c0a61e21c42 Modified Files -- doc/src/sgml/syntax.sgml | 34 + src/backend/catalog/information_schema.sql | 6 +- src/backend/catalog/sql_features.txt | 1 + src/backend/parser/parse_node.c| 37 +- src/backend/parser/scan.l | 101 +++ src/backend/utils/adt/numutils.c | 185 +++ src/fe_utils/psqlscan.l| 78 +--- src/interfaces/ecpg/preproc/pgc.l | 106 +--- src/test/regress/expected/int2.out | 92 ++ src/test/regress/expected/int4.out | 92 ++ src/test/regress/expected/int8.out | 92 ++ src/test/regress/expected/numerology.out | 193 - src/test/regress/sql/int2.sql | 26 src/test/regress/sql/int4.sql | 26 src/test/regress/sql/int8.sql | 26 src/test/regress/sql/numerology.sql| 51 +++- 16 files changed, 1028 insertions(+), 118 deletions(-)
