Thread
Commits
-
Do not return NULL for error cases in satisfies_hash_partition().
- fea5960fafb0 13.2 landed
- 84e316228823 11.11 landed
- 54a940644073 12.6 landed
- 4025e6c46620 14.0 landed
-
Returning NULL from satisfies_hash_partition() is a bad idea
Tom Lane <tgl@sss.pgh.pa.us> — 2020-11-11T22:46:59Z
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