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