Re: BUG #19816: PL/Python SD dictionary is split by input collation in 19rc1

Hi,

Thanks for the quick patch. We applied it on top of 19rc1 and the plpython
suite passes. A
trigger function used by two triggers on the same table, and a function
returning record called
with two column definition lists, now share SD as in 18, and the same
trigger function on another
table keeps its own SD, also as in 18.

As for variables set with "global", our code does not use them, so that
does not matter to us.

Just in case it is useful: while testing we noticed that after a
redefinition that is rolled back,
a cache entry created later in the same session gets its own SD. It only
affects the session that
rolled back and we don't run into it in practice, so it's up to you whether
it matters:

CREATE FUNCTION g(t text) RETURNS int AS $$
SD["n"] = SD.get("n", 0) + 1
return SD["n"]
$$ LANGUAGE plpython3u;
SELECT g('a'); -- 1
BEGIN;
CREATE OR REPLACE FUNCTION g(t text) RETURNS int AS $$
SD["n"] = SD.get("n", 0) + 1
return SD["n"]
$$ LANGUAGE plpython3u;
ROLLBACK;
SELECT g('a'), g('a' COLLATE "C"); -- 2 | 1

Also, a minor note on the new regression test: the CREATE OR REPLACE part
returns 1 with or
without the patch, and the trigger case isn't covered.

Thanks again,
Marcos

El lun, 9 nov 2026 a la(s) 2:21 a.m., shihao zhong (zhong950419(at)gmail(dot)com)
escribió:

> Hi,
>
> Thanks for reporting that.
>
> The attached patch keeps SD in its own hash keyed by function OID and
> trigger relation, as 18 did. So every cache entry of a function shares
> it.
>
> Variables set with "global" in the function body are still split, since
> sharing t
> hose would also mean sharing the call stack state. I left that alone, but
> I
> can look at it if you think it matters.
>
> This is a 19 regression, I'll add it to the open items.
>