Switch opclass option functions to be STRICT (currently non-STRICT)
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253443psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 23, 2026 at 08:22 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253443_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253443_1 && git checkout t253443_1Patchset v1 (message #1) is on t253443_1
Hi all,
During a recent review of 911e70207703 for a different issue, it has
come up to me (and also Tom, in CC) that the following functions are
marked as not strict (core backend or contrib/):
brin_bloom_options
brin_minmax_multi_options
gtsvector_options
ghstore_options
gtrgm_options
g_int_options
g_intbig_options
_ltree_gist_options
ltree_gist_options
However, if one looks at the internals of any of these functions, it
is easy to note that they are not able to handle NULL inputs at all,
leading to a crash (aka 8f7e35b08ad5). It looks like a mistake to me
to declare them as not STRICT, while their internals are written to
not be able to handle NULL.
Most of these functions are in contrib/, and it feels overengineered
to bump the modules just to mark these functions as STRICT, so I
propose to have them do nothing if given a NULL input instead. The
three opclass option functions in core can be flipped more easily in
pg_proc.dat.
Comments or opinions?
--
Michael
On Mon, Aug 17, 2026 at 09:33:01AM -0400, Tom Lane wrote:
Probably a mistake, but it's of no consequence. These all take
type internal so they can't be called from SQL; if they could be,
the hazards from passing a not-NULL pointer would be far worse
than what happens with a NULL. I can't get excited about doing
work to change it.
Of course, I just mean that as an extra defense-in-depth failures so
as these can never be reused for holes similar of the internal
business dealt with recently, in terms of dereference, and because
NULL opclass options are the same as nothing as far as my
understanding of the backend goes.
If you don't feel strongly about this proposal, that's fine by me.
--
Michael
Import Notes
Reply to msg id not found: 740873.1786973581@sss.pgh.pa.us