| 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 |
| 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 |