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

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