postgresql.git/contrib/hstore_plpython, branch master

hstore: Rework module to use Size and {add,mul}_size for allocation sizes

2026-08-18T04:44:04Z

hstore has been relying on a set of int/int32 to count the total length of all the keys and values constructed, relying on the maximum values of the arguments rather than proper bound checks. As proved in the reported thread, these counters could overflow and wrap, leading to incorrect allocations. This commit replaces the int/int32 values with a set of Size values, with add_size() and mul_size() in charge of checking for overflows when constructing hstore values before doing any allocation. The changes that matter in terms of the report are mostly in hstore_io.c. hstore_compat.c is adjusted for consistency, to keep the allocation maths uniform across the module. This is an old bug. A backpatch should perhaps be done but I cannot get excited about a change like that in stable branches. Reported-by: Man Zeng Author: Tender Wang Author: Michael Paquier Discussion: https://postgr.es/m/CAHewXNmfD6-9MDxgpRfTzjVj0mhBw3JMoNOHeTiPOjZGhNzd=g@mail.gmail.com

plpython: Fix NULL pointer dereferences for broken sequence and mapping objects

2026-06-29T02:38:39Z

PL/Python and its hstore and jsonb transforms build SQL values from Python containers by calling Python C API functions that can return NULL, and in several places the result was used without first checking it. On the sequence side, PySequence_GetItem() is used when converting a returned sequence into a SQL array or composite value, when reading the argument list passed to plpy.execute() or plpy.cursor(), and when reading the list of type names given to plpy.prepare(). On the mapping side, the hstore and jsonb transforms call PyMapping_Size() and PyMapping_Items() and then index the result with PyList_GetItem() and PyTuple_GetItem(). All of these return NULL (or -1), with a Python exception set, for a broken object: for example one whose __getitem__() or items() raises, or which reports a length that disagrees with what it actually yields. The unchecked result was then dereferenced, crashing the backend. Fix this by checking the result of each call and reporting a regular error if it failed, so that the underlying Python exception is surfaced instead of taking down the session. Author: Richard Guo Reviewed-by: Ayush Tiwari Discussion: https://postgr.es/m/CAMbWs49BKM9wP6m8bCXEpHwQKp7usvOGV6Jf=J7FYr_BCpxLqg@mail.gmail.com Backpatch-through: 14

Use palloc_array() in a few more places to avoid overflow

2026-05-11T18:27:55Z

These could overflow on 32-bit systems. Backpatch-through: 14 Security: CVE-2026-6473

Change StaticAssertVariableIsOfType to be a declaration

2026-02-03T07:46:02Z

This allows moving the uses to more natural and useful positions. Also, a declaration is the more native use of static assertions in C. Reviewed-by: Bertrand Drouvot Discussion: https://www.postgresql.org/message-id/flat/2273bc2a-045d-4a75-8584-7cd9396e5534%40eisentraut.org

Rename AssertVariableIsOfType to StaticAssertVariableIsOfType

2026-02-03T07:45:24Z

This keeps run-time assertions and static assertions clearly separate. Reviewed-by: Bertrand Drouvot Discussion: https://www.postgresql.org/message-id/flat/2273bc2a-045d-4a75-8584-7cd9396e5534%40eisentraut.org

Update copyright for 2026

2026-01-01T18:24:10Z

Backpatch-through: 14

Remove circular #include's between plpython.h and plpy_util.h.

2025-04-27T15:43:02Z

plpython.h included plpy_util.h, simply on the grounds that "it's easier to just include it everywhere". However, plpy_util.h must include plpython.h, or it won't pass headerscheck. While the resulting circularity doesn't have any immediate bad effect, it's poor design. We have seen serious messes arise in the past from overly-broad inclusion footprints created by such circularities, so let's establish a project policy against it. To fix, just replace *.c files' inclusions of plpython.h with plpy_util.h. They'll pull in plpython.h indirectly; indeed, almost all have already done so via inclusions of other plpy_xxx.h headers. (Any extensions using plpython.h can do likewise without breaking the compatibility of their code with prior Postgres versions.) Reported-by: Bertrand Drouvot Author: Tom Lane Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/aAxQ6fcY5QQV1lo3@ip-10-97-1-34.eu-west-3.compute.internal

Use PG_MODULE_MAGIC_EXT in our installable shared libraries.

2025-03-26T15:11:02Z

It seems potentially useful to label our shared libraries with version information, now that a facility exists for retrieving that. This patch labels them with the PG_VERSION string. There was some discussion about using semantic versioning conventions, but that doesn't seem terribly helpful for modules with no SQL-level presence; and for those that do have SQL objects, we typically expect them to support multiple revisions of the SQL definitions, so it'd still not be very helpful. I did not label any of src/test/modules/. It seems unnecessary since we don't install those, and besides there ought to be someplace that still provides test coverage for the original PG_MODULE_MAGIC macro. Author: Tom Lane Discussion: https://postgr.es/m/dd4d1b59-d0fe-49d5-b28f-1e463b68fa32@gmail.com

Use @extschema:name@ notation in contrib transform modules.

2025-01-09T20:16:56Z

Harden hstore_plperl, hstore_plpython, and ltree_plpython against search-path-based attacks by using @extschema:name@ notation to refer to the underlying hstore or ltree data type. This allows removal of the previous documentation warning suggesting that they must be installed in the same schema as the underlying data type. In passing, also improve a para in extend.sgml to suggest using @extschema:name@ for such purposes. Discussion: https://postgr.es/m/692480.1736021695@sss.pgh.pa.us

2025-01-01T16:21:55Z

Backpatch-through: 13