From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Do not return NULL for error cases in satisfies_hash_partition() |
Date: | 2020-11-16 21:40:46 |
Message-ID: | E1kemEw-0006fr-DX@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Do not return NULL for error cases in satisfies_hash_partition().
Since this function is used as a CHECK constraint condition,
returning NULL is tantamount to returning TRUE, which would have the
effect of letting in a row that doesn't satisfy the hash condition.
Admittedly, the cases for which this is done should be unreachable
in practice, but that doesn't make it any less a bad idea. It also
seems like a dartboard was used to decide which error cases should
throw errors as opposed to returning NULL.
For the checks for NULL input values, I just switched it to returning
false. There's some argument that an error would be better; but the
case really should be can't-happen in a generated hash constraint,
so it's likely not worth more code for.
For the parent-relation-open-failure case, it seems like we might
as well let relation_open throw an error, instead of having an
impossible-to-diagnose constraint failure.
Back-patch to v11 where this code came in.
Discussion: https://postgr.es/m/24067.1605134819@sss.pgh.pa.us
Branch
------
REL_12_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/54a94064407375ac3c108e1b791303a42baf030a
Modified Files
--------------
src/backend/partitioning/partbounds.c | 15 +++++++--------
src/test/regress/expected/hash_part.out | 10 +++-------
2 files changed, 10 insertions(+), 15 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-11-16 22:43:55 | pgsql: Rename PGPROC->vacuumFlags to statusFlags |
Previous Message | Tom Lane | 2020-11-16 20:16:53 | pgsql: Use "true" not "TRUE" in one ICU function call. |