So far as I can tell, the partition machinery is critically dependent
on the idea that partition constraint conditions can never return
NULL, only true or false. This is explicitly noted in the comments in
get_qual_for_list, for instance, and it's visibly true by construction
for both list and range constraints.
But hash partition constraints are just calls to
satisfies_hash_partition(), and look what we've got there:
/* Return null if the parent OID, modulus, or remainder is NULL. */
if (PG_ARGISNULL(0) || PG_ARGISNULL(1) || PG_ARGISNULL(2))
PG_RETURN_NULL();
parent = try_relation_open(parentId, AccessShareLock);
if (parent == NULL)
PG_RETURN_NULL();
OK, the first one probably shouldn't happen, but it's far from clear that
the second cannot. If we did return NULL, that would be taken as a "pass"
of the constraint, possibly allowing a non-matching row to be inserted
into a partition.
So this seems like a seriously bad idea. I don't have a strong position
on whether it'd be better to return FALSE (causing a constraint failure
error) or just throw an error outright. But we can't leave it like this.
regards, tom lane
