| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | shihao zhong <zhong950419(at)gmail(dot)com> |
| Cc: | Marcos Castedo <marcos(dot)castedo(at)anachronics(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19816: PL/Python SD dictionary is split by input collation in 19rc1 |
| Date: | 2026-11-11 16:40:42 |
| Message-ID: | 3245516.1794415242@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
shihao zhong <zhong950419(at)gmail(dot)com> writes:
> I have a proposal. SD stays with the cache entry, and plpython leaves
> the input collation out of its cache key.
Yeah, I had been wondering if we should go in that direction.
However ...
It occurred to me to consult the fine manual, and I read this:
The global dictionary SD is available to store private data
between repeated calls to the same function.
Full stop. So that's already a lie, and we need to fix it.
However, this would certainly not leave a reader with the
impression that different argument types or collations would
give you different SDs. In fact, it leaves the impression
that different uses of the same trigger function should share
SD. But that's never been true, and I'm sure there are users
out there who depend on the per-trigger-relation behavior.
So I'm now coming around to the conclusion that bug compatibility
with the old behavior is the way to go. Maybe we will rethink
that when/if we get around to supporting polymorphic arguments,
but we don't have to make a decision about that today. If we
split off a separate hashtable as Shihao's v1 patch does, then
we've successfully decoupled the SD behavior from funccache.c's
rules, and we will be free to go either way when the time comes.
So I think Shihao's patch is the right thing (at least approximately,
I haven't read it in detail), and I'll move forward with that.
The manual's text needs to be updated to something like
The global dictionary SD is available to store private data
between repeated calls to the same function within a session.
Each PL/Python function has its own instance of SD, except
that for trigger functions, there is one instance of SD
per function per triggered-on relation.
As a separate matter that is an optimization not a bug fix,
it might be interesting to suppress collation from plpython's
funccache keys, just so we don't get useless redundant cache
entries. But we can leave that for another day.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | JF Intelligent Automation | 2026-11-11 16:55:31 | PostgreSQL 17.11 initdb on Windows: restricted-token errors 87 and 0 despite exit status 0 |
| Previous Message | PG Bug reporting form | 2026-11-11 16:24:27 | BUG #19891: pg_restore ignores an explicitly empty -F argument |