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

Hi Tom,

Fair question. I should say first that we don't use non-default collations
anywhere. What breaks
for us is an optional text argument: a call that passes it has the default
collation as input
collation, and a call that omits it has none, so the two calls get
different cache entries and
different SDs. We have a function shaped like this, which stores a value
with one call and reads
it back with another:

CREATE DOMAIN ver AS text;
CREATE FUNCTION installing_version(p_id int4, p_version ver DEFAULT NULL)
RETURNS ver AS $$
if p_version is not None:
SD[p_id] = p_version
return p_version
return SD.get(p_id)
$$ LANGUAGE plpython3u;

SELECT installing_version(1, '9.0.2'); -- 9.0.2
SELECT installing_version(1); -- 19rc1: NULL; with the patch:
9.0.2

Nothing in PL/Python exposes the input collation to the function body, so
the function's author
has no way to see or work around the split. The trigger relation and
argument types differ in
that respect, since the code sees the relation in TD, and with polymorphic
arguments it would get
values of different Python types. Whether that is the right line to draw is
your call; none of our
functions that use SD are triggers or polymorphic, so we don't depend on #2
or #3 either way.

Regards,
Marcos

El lun, 9 nov 2026 a la(s) 4:21 p.m., Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) escribió:

> shihao zhong <zhong950419(at)gmail(dot)com> writes:
> > 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.
>
> I'm kind of unconvinced about both this bug report and this patch.
> It seems fundamentally schizophrenic, with no real design theory
> beyond "let's be bug-compatible with the old behavior". If the
> idea of SD is to be shared across all instances of the same function,
> why is it OK to have a different SD per trigger relation?
>
> The thing that is primarily worrying me here is what shall we do when
> plpython starts supporting polymorphic arguments/results? (Maybe
> that's not ever gonna happen, but I think it's just something nobody's
> gotten around to.) We will want a separate function cache entry for
> each argument type combination seen in a session, for the same reason
> as other PLs: so we can cache type-appropriate conversion functions.
> With the code as it stands today, that would result in a different SD
> for each argument type combination. Maybe that's sane, maybe it is
> not. You could argue that f(anyelement) is just an abstract prototype
> for a bunch of different concrete functions f(int), f(int8), etc, and
> that users would rather those concrete functions not share SDs. If
> what was being kept in SD was at all argument-type-specific then you
> likely would want that behavior.
>
> So basically, I see four potential contributors to a cache key for SD:
>
> 1. Function/procedure OID
> 2. Trigger relation OID, if a trigger
> 3. Actual argument types
> 4. Collation
>
> It's not very apparent to me why #2 is a legitimate cache key but
> #3 and #4 are not. Maybe that's the right thing, but is there any
> defensible reasoning behind it?
>
> regards, tom lane
>