Switch opclass option functions to be STRICT (currently non-STRICT)

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Subject: Switch opclass option functions to be STRICT (currently non-STRICT)
Date: 2026-08-17 08:04:14
Message-ID: aoLAfrom5kYM9ZAt@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
0001-Fix-handling-of-NULL-input-in-opclass-option-functio.patch text/plain 6.1 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2026-08-17 08:09:09 RE: Per-table resync for logical replication subscriptions
Previous Message 陈列行 2026-08-17 08:03:56 Redundant outer DISTINCT adds Sort and Unique above INTERSECT