Thread

Commits

  1. Do not return NULL for error cases in satisfies_hash_partition().

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