pgsql: Fix use of incorrect TupleTableSlot in DISTINCT aggregates

Fix use of incorrect TupleTableSlot in DISTINCT aggregates 1349d2790 added code to allow DISTINCT and ORDER BY aggregates to work more efficiently by using presorted input. That commit added some code that made use of the AggState's tmpcontext and adjusted the ecxt_outertuple and ecxt_innertuple

pgsql: Fix use of incorrect TupleTableSlot in DISTINCT aggregates

Fix use of incorrect TupleTableSlot in DISTINCT aggregates 1349d2790 added code to allow DISTINCT and ORDER BY aggregates to work more efficiently by using presorted input. That commit added some code that made use of the AggState's tmpcontext and adjusted the ecxt_outertuple and ecxt_innertuple

pgsql: Track conflict_reason in pg_replication_slots.

Track conflict_reason in pg_replication_slots. This patch changes the existing 'conflicting' field to 'conflict_reason' in pg_replication_slots. This new field indicates the reason for the logical slot's conflict with recovery. It is always NULL for physical slots, as well as for logical slots

pgsql: Update copyright for 2024

Update copyright for 2024 Reported-by: Michael Paquier Discussion: https://postgr.es/m/zzktdpxbbmt3c...@paquier.xyz Backpatch-through: 12 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/79a2af3e7277122858da61eff8177d5fe487ce92 Modified Files

pgsql: Update copyright for 2024

Update copyright for 2024 Reported-by: Michael Paquier Discussion: https://postgr.es/m/zzktdpxbbmt3c...@paquier.xyz Backpatch-through: 12 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/42afeae7b6db06c04ee5de7226b6b86e41b11da2 Modified Files

pgsql: Update copyright for 2024

Update copyright for 2024 Reported-by: Michael Paquier Discussion: https://postgr.es/m/zzktdpxbbmt3c...@paquier.xyz Backpatch-through: 12 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/49fa18390cfbd03956a4820910777c3d6585d5a7 Modified Files

pgsql: Update copyright for 2024

Update copyright for 2024 Reported-by: Michael Paquier Discussion: https://postgr.es/m/zzktdpxbbmt3c...@paquier.xyz Backpatch-through: 12 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/727cf6f6d31cf5a8cbe144207f22d0b76583f4d0 Modified Files

pgsql: Update copyright for 2024

Update copyright for 2024 Reported-by: Michael Paquier Discussion: https://postgr.es/m/zzktdpxbbmt3c...@paquier.xyz Backpatch-through: 12 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/596eeb10972b30d3c3d6f8368b33378837bcd261 Modified Files

pgsql: doc: fix typo "vertexes" -> "vertices"

doc: fix typo "vertexes" -> "vertices" The "vertexes" spelling is also valid, but we consistently use "vertices" elsewhere. Author: Dagfinn Ilmari Mannsåker Reviewed-by: Shubham Khanna Discussion: https://postgr.es/m/87le9fmi01@wibble.ilmari.org Branch -- master Details ---

pgsql: Avoid masking EOF (no-password-supplied) conditions in auth.c.

Avoid masking EOF (no-password-supplied) conditions in auth.c. CheckPWChallengeAuth() would return STATUS_ERROR if the user does not exist or has no password assigned, even if the client disconnected without responding to the password challenge (as libpq often will, for example). We should

pgsql: Avoid masking EOF (no-password-supplied) conditions in auth.c.

Avoid masking EOF (no-password-supplied) conditions in auth.c. CheckPWChallengeAuth() would return STATUS_ERROR if the user does not exist or has no password assigned, even if the client disconnected without responding to the password challenge (as libpq often will, for example). We should

pgsql: Avoid masking EOF (no-password-supplied) conditions in auth.c.

Avoid masking EOF (no-password-supplied) conditions in auth.c. CheckPWChallengeAuth() would return STATUS_ERROR if the user does not exist or has no password assigned, even if the client disconnected without responding to the password challenge (as libpq often will, for example). We should

pgsql: Avoid masking EOF (no-password-supplied) conditions in auth.c.

Avoid masking EOF (no-password-supplied) conditions in auth.c. CheckPWChallengeAuth() would return STATUS_ERROR if the user does not exist or has no password assigned, even if the client disconnected without responding to the password challenge (as libpq often will, for example). We should

pgsql: Avoid masking EOF (no-password-supplied) conditions in auth.c.

Avoid masking EOF (no-password-supplied) conditions in auth.c. CheckPWChallengeAuth() would return STATUS_ERROR if the user does not exist or has no password assigned, even if the client disconnected without responding to the password challenge (as libpq often will, for example). We should

pgsql: Avoid masking EOF (no-password-supplied) conditions in auth.c.

Avoid masking EOF (no-password-supplied) conditions in auth.c. CheckPWChallengeAuth() would return STATUS_ERROR if the user does not exist or has no password assigned, even if the client disconnected without responding to the password challenge (as libpq often will, for example). We should

Re: pgsql: Reorganise jsonpath operators and methods

On 03.01.24 16:50, Andrew Dunstan wrote: On 2024-01-03 We 05:49, Peter Eisentraut wrote: Reorganise jsonpath operators and methods Various jsonpath operators and methods add various keywords, switch cases, and documentation entries in some order.  However, they are not consistent; reorder

pgsql: Second attempt at organizing jsonpath operators and methods

Second attempt at organizing jsonpath operators and methods Second attempt at 283a95da923. Since we can't reorder the enum values of JsonPathItemType, instead reorder the switch cases where they are used to generally follow the order of the enum values, for better maintainability. Branch --

pgsql: Revert "Reorganise jsonpath operators and methods"

Revert "Reorganise jsonpath operators and methods" This reverts commit 283a95da923605c1cc148155db2d865d0801b419. The reordering of JsonPathItemType affects the binary on-disk compatibility of the jsonpath type, so we must not change it. Revert for now and consider. Branch -- master

pgsql: Doc: Python's control flow construct is try/except not try/catch

Doc: Python's control flow construct is try/except not try/catch. Very ancient thinko, dating evidently to 22690719e. Spotted by gweatherby. Discussion: https://postgr.es/m/170423637139.1288848.11840082988774620...@wrigleys.postgresql.org Branch -- REL_16_STABLE Details ---

pgsql: Doc: Python's control flow construct is try/except not try/catch

Doc: Python's control flow construct is try/except not try/catch. Very ancient thinko, dating evidently to 22690719e. Spotted by gweatherby. Discussion: https://postgr.es/m/170423637139.1288848.11840082988774620...@wrigleys.postgresql.org Branch -- REL_14_STABLE Details ---

pgsql: Doc: Python's control flow construct is try/except not try/catch

Doc: Python's control flow construct is try/except not try/catch. Very ancient thinko, dating evidently to 22690719e. Spotted by gweatherby. Discussion: https://postgr.es/m/170423637139.1288848.11840082988774620...@wrigleys.postgresql.org Branch -- REL_13_STABLE Details ---

pgsql: Doc: Python's control flow construct is try/except not try/catch

Doc: Python's control flow construct is try/except not try/catch. Very ancient thinko, dating evidently to 22690719e. Spotted by gweatherby. Discussion: https://postgr.es/m/170423637139.1288848.11840082988774620...@wrigleys.postgresql.org Branch -- REL_15_STABLE Details ---

pgsql: Doc: Python's control flow construct is try/except not try/catch

Doc: Python's control flow construct is try/except not try/catch. Very ancient thinko, dating evidently to 22690719e. Spotted by gweatherby. Discussion: https://postgr.es/m/170423637139.1288848.11840082988774620...@wrigleys.postgresql.org Branch -- REL_12_STABLE Details ---

pgsql: Doc: Python's control flow construct is try/except not try/catch

Doc: Python's control flow construct is try/except not try/catch. Very ancient thinko, dating evidently to 22690719e. Spotted by gweatherby. Discussion: https://postgr.es/m/170423637139.1288848.11840082988774620...@wrigleys.postgresql.org Branch -- master Details ---

Re: pgsql: Reorganise jsonpath operators and methods

On 2024-01-03 We 05:49, Peter Eisentraut wrote: Reorganise jsonpath operators and methods Various jsonpath operators and methods add various keywords, switch cases, and documentation entries in some order. However, they are not consistent; reorder them for better maintainability or

pgsql: Fix defects in PrepareForIncrementalBackup.

Fix defects in PrepareForIncrementalBackup. Swap the arguments to TimestampDifferenceMilliseconds so that we get a positive answer instead of zero. Then use the result of that computation instead of ignoring it. Per reports from Alexander Lakhin. Discussion:

Re: pgsql: Make all Perl warnings fatal

On 03.01.24 12:21, Bharath Rupireddy wrote: On Sat, Dec 30, 2023 at 5:03 AM Peter Eisentraut wrote: I was already on it. It looks like it's okay now. I'm attaching a patch to FATAL-ize warnings in new TAP tests added by commits 9a17be1e and 4710b67d. Committed, thanks.

pgsql: Make Perl warnings fatal in newly added TAP tests

Make Perl warnings fatal in newly added TAP tests New TAP tests added by commits 9a17be1e and 4710b67d missed to convert warnings to FATAL. This commit fixes that. Author: Bharath Rupireddy Branch -- master Details ---

Re: pgsql: Follow-up fixes for "Make all Perl warnings fatal"

On 02.01.24 15:49, Andrew Dunstan wrote: On 2023-12-29 Fr 17:56, Peter Eisentraut wrote: Follow-up fixes for "Make all Perl warnings fatal" Mostly, we need to check whether $ENV{PG_TEST_EXTRA} is set before doing regular expression matches against it. This reads a bit oddly to me. -elsif

Re: pgsql: Make all Perl warnings fatal

On Sat, Dec 30, 2023 at 5:03 AM Peter Eisentraut wrote: > > I was already on it. It looks like it's okay now. I'm attaching a patch to FATAL-ize warnings in new TAP tests added by commits 9a17be1e and 4710b67d. Thoughts? -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source

pgsql: Reorganise jsonpath operators and methods

Reorganise jsonpath operators and methods Various jsonpath operators and methods add various keywords, switch cases, and documentation entries in some order. However, they are not consistent; reorder them for better maintainability or readability. Author: Jeevan Chalke Discussion:

pgsql: Add numeric_int8_opt_error() to optionally suppress errors

Add numeric_int8_opt_error() to optionally suppress errors This matches the existing numeric_int4_opt_error() (see commit 16d489b0fe). It will be used by a future JSON-related patch, which wants to report errors in its own way and thus does not want the internal functions to throw any error.

pgsql: Refactor: separate function to find all objects depending on a c

Refactor: separate function to find all objects depending on a column Move code from ATExecAlterColumnType() that finds the all the objects that depend on the column to a separate function. A future patch will reuse this code. Author: Amul Sul Discussion: