pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1.

Fix infer_arbiter_indexes() to not assume resultRelation is 1. infer_arbiter_indexes failed to renumber varnos in index expressions or predicates that it got from the catalogs. This escaped detection up to now because the stored varnos in such trees will be 1, and an INSERT's result relation is

pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1.

Fix infer_arbiter_indexes() to not assume resultRelation is 1. infer_arbiter_indexes failed to renumber varnos in index expressions or predicates that it got from the catalogs. This escaped detection up to now because the stored varnos in such trees will be 1, and an INSERT's result relation is

pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1.

Fix infer_arbiter_indexes() to not assume resultRelation is 1. infer_arbiter_indexes failed to renumber varnos in index expressions or predicates that it got from the catalogs. This escaped detection up to now because the stored varnos in such trees will be 1, and an INSERT's result relation is

pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1.

Fix infer_arbiter_indexes() to not assume resultRelation is 1. infer_arbiter_indexes failed to renumber varnos in index expressions or predicates that it got from the catalogs. This escaped detection up to now because the stored varnos in such trees will be 1, and an INSERT's result relation is

pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1.

Fix infer_arbiter_indexes() to not assume resultRelation is 1. infer_arbiter_indexes failed to renumber varnos in index expressions or predicates that it got from the catalogs. This escaped detection up to now because the stored varnos in such trees will be 1, and an INSERT's result relation is

pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1.

Fix infer_arbiter_indexes() to not assume resultRelation is 1. infer_arbiter_indexes failed to renumber varnos in index expressions or predicates that it got from the catalogs. This escaped detection up to now because the stored varnos in such trees will be 1, and an INSERT's result relation is

pgsql: Tighten test_predtest's input checks, and improve error messages

Tighten test_predtest's input checks, and improve error messages. test_predtest() neglected to consider the possibility that SPI_plan_get_cached_plan would return NULL. This led to a core dump if the input (incorrectly) contains more than one SQL command. While here, let's expend more than zero

pgsql: Tighten test_predtest's input checks, and improve error messages

Tighten test_predtest's input checks, and improve error messages. test_predtest() neglected to consider the possibility that SPI_plan_get_cached_plan would return NULL. This led to a core dump if the input (incorrectly) contains more than one SQL command. While here, let's expend more than zero

pgsql: Tighten test_predtest's input checks, and improve error messages

Tighten test_predtest's input checks, and improve error messages. test_predtest() neglected to consider the possibility that SPI_plan_get_cached_plan would return NULL. This led to a core dump if the input (incorrectly) contains more than one SQL command. While here, let's expend more than zero

pgsql: Tighten test_predtest's input checks, and improve error messages

Tighten test_predtest's input checks, and improve error messages. test_predtest() neglected to consider the possibility that SPI_plan_get_cached_plan would return NULL. This led to a core dump if the input (incorrectly) contains more than one SQL command. While here, let's expend more than zero

pgsql: Tighten test_predtest's input checks, and improve error messages

Tighten test_predtest's input checks, and improve error messages. test_predtest() neglected to consider the possibility that SPI_plan_get_cached_plan would return NULL. This led to a core dump if the input (incorrectly) contains more than one SQL command. While here, let's expend more than zero

pgsql: Tighten test_predtest's input checks, and improve error messages

Tighten test_predtest's input checks, and improve error messages. test_predtest() neglected to consider the possibility that SPI_plan_get_cached_plan would return NULL. This led to a core dump if the input (incorrectly) contains more than one SQL command. While here, let's expend more than zero

pgsql: Reject modifying a temp table of another session with ALTER TABL

Reject modifying a temp table of another session with ALTER TABLE. Normally this case isn't even reachable by non-superusers, since permissions checks prevent naming such a table. However, it is possible to make it happen by altering a parent table whose child is another session's temp table.

pgsql: Reject modifying a temp table of another session with ALTER TABL

Reject modifying a temp table of another session with ALTER TABLE. Normally this case isn't even reachable by non-superusers, since permissions checks prevent naming such a table. However, it is possible to make it happen by altering a parent table whose child is another session's temp table.

pgsql: Reject modifying a temp table of another session with ALTER TABL

Reject modifying a temp table of another session with ALTER TABLE. Normally this case isn't even reachable by non-superusers, since permissions checks prevent naming such a table. However, it is possible to make it happen by altering a parent table whose child is another session's temp table.

pgsql: Reject modifying a temp table of another session with ALTER TABL

Reject modifying a temp table of another session with ALTER TABLE. Normally this case isn't even reachable by non-superusers, since permissions checks prevent naming such a table. However, it is possible to make it happen by altering a parent table whose child is another session's temp table.

pgsql: Reject modifying a temp table of another session with ALTER TABL

Reject modifying a temp table of another session with ALTER TABLE. Normally this case isn't even reachable by non-superusers, since permissions checks prevent naming such a table. However, it is possible to make it happen by altering a parent table whose child is another session's temp table.

pgsql: Reject modifying a temp table of another session with ALTER TABL

Reject modifying a temp table of another session with ALTER TABLE. Normally this case isn't even reachable by non-superusers, since permissions checks prevent naming such a table. However, it is possible to make it happen by altering a parent table whose child is another session's temp table.

pgsql: Fix behavior of stable functions called from a CALL's argument l

Fix behavior of stable functions called from a CALL's argument list. If the CALL is within an atomic context (e.g. there's an outer transaction block), _SPI_execute_plan should acquire a fresh snapshot to execute any such functions with. We failed to do that and instead passed them the Portal

pgsql: Fix behavior of stable functions called from a CALL's argument l

Fix behavior of stable functions called from a CALL's argument list. If the CALL is within an atomic context (e.g. there's an outer transaction block), _SPI_execute_plan should acquire a fresh snapshot to execute any such functions with. We failed to do that and instead passed them the Portal

pgsql: Fix behavior of stable functions called from a CALL's argument l

Fix behavior of stable functions called from a CALL's argument list. If the CALL is within an atomic context (e.g. there's an outer transaction block), _SPI_execute_plan should acquire a fresh snapshot to execute any such functions with. We failed to do that and instead passed them the Portal

pgsql: Fix behavior of stable functions called from a CALL's argument l

Fix behavior of stable functions called from a CALL's argument list. If the CALL is within an atomic context (e.g. there's an outer transaction block), _SPI_execute_plan should acquire a fresh snapshot to execute any such functions with. We failed to do that and instead passed them the Portal

pgsql: Fix behavior of stable functions called from a CALL's argument l

Fix behavior of stable functions called from a CALL's argument list. If the CALL is within an atomic context (e.g. there's an outer transaction block), _SPI_execute_plan should acquire a fresh snapshot to execute any such functions with. We failed to do that and instead passed them the Portal

pgsql: Fix behavior of stable functions called from a CALL's argument l

Fix behavior of stable functions called from a CALL's argument list. If the CALL is within an atomic context (e.g. there's an outer transaction block), _SPI_execute_plan should acquire a fresh snapshot to execute any such functions with. We failed to do that and instead passed them the Portal

pgsql: Fix failure with SQL-procedure polymorphic output arguments in v

Fix failure with SQL-procedure polymorphic output arguments in v12. Before the v13-era commit 913bbd88d, check_sql_fn_retval fails to resolve polymorphic output types and then just throws up its hands and assumes the check will be made at runtime. I think that's true for ordinary functions

pgsql: Fix failure with SQL-procedure polymorphic output arguments in v

Fix failure with SQL-procedure polymorphic output arguments in v12. Before the v13-era commit 913bbd88d, check_sql_fn_retval fails to resolve polymorphic output types and then just throws up its hands and assumes the check will be made at runtime. I think that's true for ordinary functions

pgsql: Fix failure with SQL-procedure polymorphic output arguments in v

Fix failure with SQL-procedure polymorphic output arguments in v12. Before the v13-era commit 913bbd88d, check_sql_fn_retval fails to resolve polymorphic output types and then just throws up its hands and assumes the check will be made at runtime. I think that's true for ordinary functions

pgsql: Fix failure with SQL-procedure polymorphic output arguments in v

Fix failure with SQL-procedure polymorphic output arguments in v12. Before the v13-era commit 913bbd88d, check_sql_fn_retval fails to resolve polymorphic output types and then just throws up its hands and assumes the check will be made at runtime. I think that's true for ordinary functions

pgsql: Fix failure with SQL-procedure polymorphic output arguments in v

Fix failure with SQL-procedure polymorphic output arguments in v12. Before the v13-era commit 913bbd88d, check_sql_fn_retval fails to resolve polymorphic output types and then just throws up its hands and assumes the check will be made at runtime. I think that's true for ordinary functions

pgsql: Fix failure with SQL-procedure polymorphic output arguments in v

Fix failure with SQL-procedure polymorphic output arguments in v12. Before the v13-era commit 913bbd88d, check_sql_fn_retval fails to resolve polymorphic output types and then just throws up its hands and assumes the check will be made at runtime. I think that's true for ordinary functions

pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements().

report from A. Kozhemyakin. Back-patch to all supported branches. Erik Wienhold and Tom Lane Discussion: https://postgr.es/m/6a2a1c40-2b2c-4a33-8b72-243c0766f...@postgrespro.ru Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff

pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements().

report from A. Kozhemyakin. Back-patch to all supported branches. Erik Wienhold and Tom Lane Discussion: https://postgr.es/m/6a2a1c40-2b2c-4a33-8b72-243c0766f...@postgrespro.ru Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff

pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements().

report from A. Kozhemyakin. Back-patch to all supported branches. Erik Wienhold and Tom Lane Discussion: https://postgr.es/m/6a2a1c40-2b2c-4a33-8b72-243c0766f...@postgrespro.ru Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff

pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements().

report from A. Kozhemyakin. Back-patch to all supported branches. Erik Wienhold and Tom Lane Discussion: https://postgr.es/m/6a2a1c40-2b2c-4a33-8b72-243c0766f...@postgrespro.ru Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff

pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements().

report from A. Kozhemyakin. Back-patch to all supported branches. Erik Wienhold and Tom Lane Discussion: https://postgr.es/m/6a2a1c40-2b2c-4a33-8b72-243c0766f...@postgrespro.ru Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff

pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements().

report from A. Kozhemyakin. Back-patch to all supported branches. Erik Wienhold and Tom Lane Discussion: https://postgr.es/m/6a2a1c40-2b2c-4a33-8b72-243c0766f...@postgrespro.ru Branch -- master Details --- https://git.postgresql.org/pg/commitdiff

Re: pgsql: Fix potential NULL pointer dereference in getIdentitySequence()

ides that the failures started earlier. What it looks like from here is that Andres messed up the installed-packages set on a lot of his animals. regards, tom lane

pgsql: Remove race conditions between ECPGdebug() and ecpg_log().

Remove race conditions between ECPGdebug() and ecpg_log(). Coverity complains that ECPGdebug is accessing debugstream without holding debug_mutex, which is a fair complaint: we should take debug_mutex while changing the settings ecpg_log looks at. In some branches it also complains about

pgsql: Remove race conditions between ECPGdebug() and ecpg_log().

Remove race conditions between ECPGdebug() and ecpg_log(). Coverity complains that ECPGdebug is accessing debugstream without holding debug_mutex, which is a fair complaint: we should take debug_mutex while changing the settings ecpg_log looks at. In some branches it also complains about

pgsql: Remove race conditions between ECPGdebug() and ecpg_log().

Remove race conditions between ECPGdebug() and ecpg_log(). Coverity complains that ECPGdebug is accessing debugstream without holding debug_mutex, which is a fair complaint: we should take debug_mutex while changing the settings ecpg_log looks at. In some branches it also complains about

pgsql: Remove race conditions between ECPGdebug() and ecpg_log().

Remove race conditions between ECPGdebug() and ecpg_log(). Coverity complains that ECPGdebug is accessing debugstream without holding debug_mutex, which is a fair complaint: we should take debug_mutex while changing the settings ecpg_log looks at. In some branches it also complains about

pgsql: Remove race conditions between ECPGdebug() and ecpg_log().

Remove race conditions between ECPGdebug() and ecpg_log(). Coverity complains that ECPGdebug is accessing debugstream without holding debug_mutex, which is a fair complaint: we should take debug_mutex while changing the settings ecpg_log looks at. In some branches it also complains about

pgsql: Remove race conditions between ECPGdebug() and ecpg_log().

Remove race conditions between ECPGdebug() and ecpg_log(). Coverity complains that ECPGdebug is accessing debugstream without holding debug_mutex, which is a fair complaint: we should take debug_mutex while changing the settings ecpg_log looks at. In some branches it also complains about

pgsql: Fix input of ISO "extended" time format for types time and timet

Fix input of ISO "extended" time format for types time and timetz. Commit 3e1a373e2 missed teaching DecodeTimeOnly the same "ptype" manipulations it added to DecodeDateTime. While likely harmless at the time, it became a problem after 5b3c59535 added an error check that ptype must be zero once

pgsql: Fix input of ISO "extended" time format for types time and timet

Fix input of ISO "extended" time format for types time and timetz. Commit 3e1a373e2 missed teaching DecodeTimeOnly the same "ptype" manipulations it added to DecodeDateTime. While likely harmless at the time, it became a problem after 5b3c59535 added an error check that ptype must be zero once

pgsql: Fix handling of extended expression statistics in CREATE TABLE L

Fix handling of extended expression statistics in CREATE TABLE LIKE. transformTableLikeClause believed that it could process extended statistics immediately because "the representation of CreateStatsStmt doesn't depend on column numbers". That was true when extended stats were first introduced,

pgsql: Fix handling of extended expression statistics in CREATE TABLE L

Fix handling of extended expression statistics in CREATE TABLE LIKE. transformTableLikeClause believed that it could process extended statistics immediately because "the representation of CreateStatsStmt doesn't depend on column numbers". That was true when extended stats were first introduced,

pgsql: Fix handling of extended expression statistics in CREATE TABLE L

Fix handling of extended expression statistics in CREATE TABLE LIKE. transformTableLikeClause believed that it could process extended statistics immediately because "the representation of CreateStatsStmt doesn't depend on column numbers". That was true when extended stats were first introduced,

pgsql: Fix handling of extended expression statistics in CREATE TABLE L

Fix handling of extended expression statistics in CREATE TABLE LIKE. transformTableLikeClause believed that it could process extended statistics immediately because "the representation of CreateStatsStmt doesn't depend on column numbers". That was true when extended stats were first introduced,

pgsql: Stamp 17beta1.

Stamp 17beta1. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/86a2d2a321215797abd1c67d9f2c52510423a97a Modified Files -- configure| 18 +- configure.ac | 2 +- meson.build | 2 +- 3 files changed, 11 insertions(+), 11 deletions(-)

pgsql: Doc: remove 66c0185a3 from release notes.

Doc: remove 66c0185a3 from release notes. Discussion: https://postgr.es/m/zktzf926vslr3...@depesz.com (also some private discussion among pgsql-release) Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e1e83a71715f1c2f0717bb66e630ca3bda79b9c1 Modified Files

pgsql: Revert commit 66c0185a3 and follow-on patches.

Revert commit 66c0185a3 and follow-on patches. This reverts 66c0185a3 (Allow planner to use Merge Append to efficiently implement UNION) as well as the follow-on commits d5d2205c8, 3b1a7eb28, 7487044d6. In addition to those, 07746a8ef had to be removed then re-applied in a different place,

pgsql: Account for optimized MinMax aggregates during SS_finalize_plan.

Account for optimized MinMax aggregates during SS_finalize_plan. We are capable of optimizing MIN() and MAX() aggregates on indexed columns into subqueries that exploit the index, rather than the normal thing of scanning the whole table. When we do this, we replace the Aggref node(s) with Params

pgsql: Account for optimized MinMax aggregates during SS_finalize_plan.

Account for optimized MinMax aggregates during SS_finalize_plan. We are capable of optimizing MIN() and MAX() aggregates on indexed columns into subqueries that exploit the index, rather than the normal thing of scanning the whole table. When we do this, we replace the Aggref node(s) with Params

pgsql: Account for optimized MinMax aggregates during SS_finalize_plan.

Account for optimized MinMax aggregates during SS_finalize_plan. We are capable of optimizing MIN() and MAX() aggregates on indexed columns into subqueries that exploit the index, rather than the normal thing of scanning the whole table. When we do this, we replace the Aggref node(s) with Params

pgsql: Account for optimized MinMax aggregates during SS_finalize_plan.

Account for optimized MinMax aggregates during SS_finalize_plan. We are capable of optimizing MIN() and MAX() aggregates on indexed columns into subqueries that exploit the index, rather than the normal thing of scanning the whole table. When we do this, we replace the Aggref node(s) with Params

pgsql: Account for optimized MinMax aggregates during SS_finalize_plan.

Account for optimized MinMax aggregates during SS_finalize_plan. We are capable of optimizing MIN() and MAX() aggregates on indexed columns into subqueries that exploit the index, rather than the normal thing of scanning the whole table. When we do this, we replace the Aggref node(s) with Params

pgsql: Add test case showing that commit d0d44049d fixed a live bug.

Add test case showing that commit d0d44049d fixed a live bug. When I committed d0d44049d (Account for optimized MinMax aggregates during SS_finalize_plan), I didn't have a test case showing that it was fixing any reachable bug. Here is one, based on bug #18465 from Hal Takahara. Without the

pgsql: Sync typedefs.list with buildfarm, for real this time.

Sync typedefs.list with buildfarm, for real this time. In commit da256a4a7, I manually added some typedef names to the buildfarm-generated list so as not to cause any formatting regressions compared to the prior manually-updated list. About half of the additions were injection-point-related

pgsql: Doc: update src/tools/pgindent/README for current practice.

Doc: update src/tools/pgindent/README for current practice. This README explains how to run pgindent, but it was written for our former practice of running pgindent only infrequently. Nowadays the plan is to keep the tree indent-clean all the time, so the typical thing is to do an incremental

pgsql: Fix handling of polymorphic output arguments for procedures.

Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call

pgsql: Fix handling of polymorphic output arguments for procedures.

Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call

pgsql: Fix handling of polymorphic output arguments for procedures.

Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call

pgsql: Fix handling of polymorphic output arguments for procedures.

Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call

pgsql: Fix handling of polymorphic output arguments for procedures.

Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call

pgsql: Fix handling of polymorphic output arguments for procedures.

Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call

pgsql: Do pre-release housekeeping on catalog data.

Do pre-release housekeeping on catalog data. Run renumber_oids.pl to move high-numbered OIDs down, as per pre-beta tasks specified by RELEASE_CHANGES. For reference, the command was ./renumber_oids.pl --first-mapped-oid 8000 --target-oid 6300 Branch -- master Details ---

pgsql: Add da256a4a7 to .git-blame-ignore-revs.

Add da256a4a7 to .git-blame-ignore-revs. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ce13f54e6055d24e21cc969f498f121c37616921 Modified Files -- .git-blame-ignore-revs | 3 +++ 1 file changed, 3 insertions(+)

pgsql: Pre-beta mechanical code beautification.

Pre-beta mechanical code beautification. Run pgindent, pgperltidy, and reformat-dat-files. The pgindent part of this is pretty small, consisting mainly of fixing up self-inflicted formatting damage from patches that hadn't bothered to add their new typedefs to typedefs.list. In order to keep it

pgsql: Remove COMMAND_TAG_NEXTTAG from enum CommandTag.

Remove COMMAND_TAG_NEXTTAG from enum CommandTag. COMMAND_TAG_NEXTTAG isn't really a valid command tag. Declaring it as if it were one prompts complaints from Coverity and perhaps other static analyzers. Our only use of it is in an entirely-unnecessary array sizing declaration, so let's just

pgsql: Doc: update the "Using EXPLAIN" examples to match current code.

Doc: update the "Using EXPLAIN" examples to match current code. A lot of the examples in this section are quite ancient and no longer match the system's current behavior. I ran through them and updated the sample output to match what I get today. Notably, it seems that the tenk1 table got a few

pgsql: Last-minute updates for release notes.

Last-minute updates for release notes. Security: CVE-2024-4317 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7b2ac0f6039f0f64d80c7488f0f718094cfb89a2 Modified Files -- doc/src/sgml/release-15.sgml | 95

pgsql: Last-minute updates for release notes.

Last-minute updates for release notes. Security: CVE-2024-4317 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a62be834aeb899dfc2e10e3cde6d0f48ba128373 Modified Files -- doc/src/sgml/release-16.sgml | 95

pgsql: Last-minute updates for release notes.

Last-minute updates for release notes. Security: CVE-2024-4317 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b7712704f0bb3dc82f286516a7057b0fa5b1d260 Modified Files -- doc/src/sgml/release-14.sgml | 95

pgsql: Fix recursive RECORD-returning plpython functions.

Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not

pgsql: Fix recursive RECORD-returning plpython functions.

Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not

pgsql: Fix recursive RECORD-returning plpython functions.

Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not

pgsql: Fix recursive RECORD-returning plpython functions.

Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not

pgsql: Fix recursive RECORD-returning plpython functions.

Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not

pgsql: Fix recursive RECORD-returning plpython functions.

Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not

pgsql: Repair ALTER EXTENSION ... SET SCHEMA.

Repair ALTER EXTENSION ... SET SCHEMA. It turns out that we broke this in commit e5bc9454e, because the code was assuming that no dependent types would appear among the extension's direct dependencies, and now they do. This isn't terribly hard to fix: just skip dependent types, expecting that we

pgsql: Make left-join removal safe under -DREALLOCATE_BITMAPSETS.

, but I've refrained for now.) This bug was exposed by the recent invention of REALLOCATE_BITMAPSETS. Commit e0477837c had installed a fix, but that went away with the reversion of SJE, so now we need to fix it again. David Rowley and Tom Lane Discussion: https://postgr.es/m/CACJufxFVQmr4

pgsql: Doc: document that triggers can break referential integrity.

. Add a para to the Triggers chapter to explain it. Laurenz Albe, David Johnston, Tom Lane Discussion: https://postgr.es/m/b81fe38fcc25a81be6e2e5b3fc1ff624130762fa.ca...@cybertec.at Branch -- master Details --- https://git.postgresql.org/pg/commitdiff

pgsql: Ensure that "pg_restore -l" reports dependent TOC entries correc

Ensure that "pg_restore -l" reports dependent TOC entries correctly. If -l was specified together with selective-restore options such as -n or -N, dependent TOC entries such as comments would be omitted from the listing, even when an actual restore would have selected them. This happened because

pgsql: Ensure that "pg_restore -l" reports dependent TOC entries correc

Ensure that "pg_restore -l" reports dependent TOC entries correctly. If -l was specified together with selective-restore options such as -n or -N, dependent TOC entries such as comments would be omitted from the listing, even when an actual restore would have selected them. This happened because

pgsql: Ensure that "pg_restore -l" reports dependent TOC entries correc

Ensure that "pg_restore -l" reports dependent TOC entries correctly. If -l was specified together with selective-restore options such as -n or -N, dependent TOC entries such as comments would be omitted from the listing, even when an actual restore would have selected them. This happened because

pgsql: Ensure that "pg_restore -l" reports dependent TOC entries correc

Ensure that "pg_restore -l" reports dependent TOC entries correctly. If -l was specified together with selective-restore options such as -n or -N, dependent TOC entries such as comments would be omitted from the listing, even when an actual restore would have selected them. This happened because

pgsql: Ensure that "pg_restore -l" reports dependent TOC entries correc

Ensure that "pg_restore -l" reports dependent TOC entries correctly. If -l was specified together with selective-restore options such as -n or -N, dependent TOC entries such as comments would be omitted from the listing, even when an actual restore would have selected them. This happened because

pgsql: Ensure that "pg_restore -l" reports dependent TOC entries correc

Ensure that "pg_restore -l" reports dependent TOC entries correctly. If -l was specified together with selective-restore options such as -n or -N, dependent TOC entries such as comments would be omitted from the listing, even when an actual restore would have selected them. This happened because

pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger

Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for

pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger

Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for

pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger

Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for

pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger

Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for

pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger

Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for

pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger

Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for

pgsql: Prevent RLS filters on ctid from breaking WHERE CURRENT OF

Prevent RLS filters on ctid from breaking WHERE CURRENT OF . The executor only supports CurrentOfExpr as the sole tidqual of a TidScan plan node. tidpath.c failed to take any particular care about that, but would just take the first ctid equality qual it could find in the target relation's

pgsql: Stamp 12.19.

Stamp 12.19. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/01aeb431c12a3388594a445ca97e71cbed410ed2 Modified Files -- configure| 18 +- configure.in | 2 +-

pgsql: Stamp 13.15.

Stamp 13.15. Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8e5faba4b918ba6142339c8f55eaa4eb99776a03 Modified Files -- configure| 18 +- configure.in | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-)

pgsql: Stamp 14.12.

Stamp 14.12. Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cf07a47dc0c3b16778291e62d730537b45da51ef Modified Files -- configure| 18 +- configure.ac | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-)

pgsql: Stamp 15.7.

Stamp 15.7. Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4a53584cf2d676e685d899d01cde18c075fbeca7 Modified Files -- configure| 18 +- configure.ac | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-)

  1   2   3   4   5   6   7   8   9   10   >