Don't invoke arbitrary code inside a possibly-aborted transaction.

The code here previously tried to call the partitioning operator, but
really the right thing to do (and the safe thing to do) is use
datumIsEqual().

Amit Langote, but I expanded the comment and fixed a compiler warning.

src/backend/catalog/partition.c

@@ -639,12 +639,20 @@ partition_bounds_equal(PartitionKey key,
 					continue;
 			}
 
-			/* Compare the actual values */
+			/*
-			cmpval = DatumGetInt32(FunctionCall2Coll(&key->partsupfunc[j],
+			 * Compare the actual values. Note that it would be both incorrect
-													 key->partcollation[j],
+			 * and unsafe to invoke the comparison operator derived from the
-													 b1->datums[i][j],
+			 * partitioning specification here.  It would be incorrect because
-													 b2->datums[i][j]));
+			 * we want the relcache entry to be updated for ANY change to the
-			if (cmpval != 0)
+			 * partition bounds, not just those that the partitioning operator
+			 * thinks are significant.  It would be unsafe because we might
+			 * reach this code in the context of an aborted transaction, and
+			 * an arbitrary partitioning operator might not be safe in that
+			 * context.  datumIsEqual() should be simple enough to be safe.
+			 */
+			if (!datumIsEqual(b1->datums[i][j], b2->datums[i][j],
+							  key->parttypbyval[j],
+							  key->parttyplen[j]))
 				return false;
 		}
 

src/backend/utils/adt/datum.c

@@ -209,6 +209,10 @@ datumTransfer(Datum value, bool typByVal, int typLen)
  * of say the representation of zero in one's complement arithmetic).
  * Also, it will probably not give the answer you want if either
  * datum has been "toasted".
+ *
+ * Do not try to make this any smarter than it currently is with respect
+ * to "toasted" datums, because some of the callers could be working in the
+ * context of an aborted transaction.
  *-------------------------------------------------------------------------
  */
 bool