pgsql: plpython: share the SD dictionary across cache entries of a func

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: plpython: share the SD dictionary across cache entries of a func
Date: 2026-11-12 16:48:13
Message-ID: E1xRXy9-00000000SRd-0Eui@gemulon.postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

plpython: share the SD dictionary across cache entries of a function.

Since commit 9bcb8a694 moved PL/Python onto funccache.c, each cache
entry gets its own SD dictionary. funccache.c builds separate entries
for the same function when the input collation differs, when a trigger
function is used by several triggers, or when the argument or result
types differ (as in polymorphic functions, a case PL/Python doesn't
yet support). This results in an unintentional change of behavior
from previous releases, which intended to share an instance of SD
across all calls of a plain function, or all calls for a given trigger
rel for a trigger function. The documentation does not suggest that
the arguments (including collation) should have anything to do with it.

However, the previous implementation had its own problem: CREATE OR
REPLACE FUNCTION caused a new SD to be generated, which is not what
you'd expect after reading the admittedly-terse documentation.
That appears to be an implementation artifact not an intentional
behavioral choice.

To fix, keep long-lived references to the SD dictionaries in a
separate hash table, keyed by function OID and (for triggers) the
relation OID, and then copy a reference into each function cache
entry. This makes SD semantics independent of what funccache.c does,
which seems like a good future-proofing choice. A function's SD will
now survive CREATE OR REPLACE FUNCTION, since that doesn't change
the function's OID.

As before, an inline DO block has its own one-use SD dictionary.

Bug: #19816
Reported-by: Marcos Castedo <marcos(dot)castedo(at)anachronics(dot)com>
Author: shihao zhong <zhong950419(at)gmail(dot)com>
Reviewed-by: Marcos Castedo <marcos(dot)castedo(at)anachronics(dot)com>
Reviewed-by: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Discussion: https://postgr.es/m/19816-921b5cbc3ee63146@postgresql.org
Backpatch-through: 19

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/c13c414c6e018fcbd9fa6e36e778a852c76a1562

Modified Files
--------------
src/pl/plpython/expected/plpython_global.out | 24 +++++++++
src/pl/plpython/plpy_main.c | 5 ++
src/pl/plpython/plpy_procedure.c | 80 +++++++++++++++++++++++++---
src/pl/plpython/sql/plpython_global.sql | 18 +++++++
src/tools/pgindent/typedefs.list | 2 +
5 files changed, 123 insertions(+), 6 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2026-11-12 17:18:36 pgsql: Make float8_regr_combine() handle edge cases like float8_regr_ac
Previous Message Tomas Vondra 2026-11-12 16:33:19 Re: pgsql: Handle numeric overflow in numeric_minmax_multi_ops