pgsql: meson: Restore implicit warning/debug/optimize flags for extensi

2024-06-07 Thread Peter Eisentraut
meson: Restore implicit warning/debug/optimize flags for extensions Meson uses warning/debug/optimize flags such as "-Wall", "-g", and "-O2" automatically based on "--warnlevel" and "--buildtype" options. And we use "--warning_level=1" and "--buildtype=debugoptimized" by default. But we need thes

pgsql: postgres_fdw: Refuse to send FETCH FIRST WITH TIES to remote ser

2024-06-07 Thread Etsuro Fujita
postgres_fdw: Refuse to send FETCH FIRST WITH TIES to remote servers. Previously, when considering LIMIT pushdown, postgres_fdw failed to check whether the query has this clause, which led to pushing false LIMIT clauses, causing incorrect results. This clause has been supported since v13, so we n

pgsql: postgres_fdw: Refuse to send FETCH FIRST WITH TIES to remote ser

2024-06-07 Thread Etsuro Fujita
postgres_fdw: Refuse to send FETCH FIRST WITH TIES to remote servers. Previously, when considering LIMIT pushdown, postgres_fdw failed to check whether the query has this clause, which led to pushing false LIMIT clauses, causing incorrect results. This clause has been supported since v13, so we n

pgsql: postgres_fdw: Refuse to send FETCH FIRST WITH TIES to remote ser

2024-06-07 Thread Etsuro Fujita
postgres_fdw: Refuse to send FETCH FIRST WITH TIES to remote servers. Previously, when considering LIMIT pushdown, postgres_fdw failed to check whether the query has this clause, which led to pushing false LIMIT clauses, causing incorrect results. This clause has been supported since v13, so we n

pgsql: postgres_fdw: Refuse to send FETCH FIRST WITH TIES to remote ser

2024-06-07 Thread Etsuro Fujita
postgres_fdw: Refuse to send FETCH FIRST WITH TIES to remote servers. Previously, when considering LIMIT pushdown, postgres_fdw failed to check whether the query has this clause, which led to pushing false LIMIT clauses, causing incorrect results. This clause has been supported since v13, so we n

pgsql: postgres_fdw: Refuse to send FETCH FIRST WITH TIES to remote ser

2024-06-07 Thread Etsuro Fujita
postgres_fdw: Refuse to send FETCH FIRST WITH TIES to remote servers. Previously, when considering LIMIT pushdown, postgres_fdw failed to check whether the query has this clause, which led to pushing false LIMIT clauses, causing incorrect results. This clause has been supported since v13, so we n

pgsql: Add more debugging information when dropping twice pgstats entry

2024-06-07 Thread Michael Paquier
Add more debugging information when dropping twice pgstats entry Floris Van Nee has reported a bug in the pgstats facility where a stats entry already dropped would get again dropped. This case should not happen, still the error generated did not offer any details about the stats entry getting dr

pgsql: Add more debugging information when dropping twice pgstats entry

2024-06-07 Thread Michael Paquier
Add more debugging information when dropping twice pgstats entry Floris Van Nee has reported a bug in the pgstats facility where a stats entry already dropped would get again dropped. This case should not happen, still the error generated did not offer any details about the stats entry getting dr

pgsql: Add more debugging information when dropping twice pgstats entry

2024-06-07 Thread Michael Paquier
Add more debugging information when dropping twice pgstats entry Floris Van Nee has reported a bug in the pgstats facility where a stats entry already dropped would get again dropped. This case should not happen, still the error generated did not offer any details about the stats entry getting dr

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

2024-06-07 Thread Tom Lane
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 sna

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

2024-06-07 Thread Tom Lane
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 sna

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

2024-06-07 Thread Tom Lane
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 sna

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

2024-06-07 Thread Tom Lane
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 sna

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

2024-06-07 Thread Tom Lane
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 sna

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

2024-06-07 Thread Tom Lane
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 sna

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

2024-06-07 Thread Tom Lane
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. We

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

2024-06-07 Thread Tom Lane
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. We

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

2024-06-07 Thread Tom Lane
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. We

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

2024-06-07 Thread Tom Lane
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. We

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

2024-06-07 Thread Tom Lane
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. We

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

2024-06-07 Thread Tom Lane
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. We

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

2024-06-07 Thread Tom Lane
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

2024-06-07 Thread Tom Lane
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

2024-06-07 Thread Tom Lane
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

2024-06-07 Thread Tom Lane
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

2024-06-07 Thread Tom Lane
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

2024-06-07 Thread Tom Lane
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