Valgrind-detected bug in partitioning code

skink has been unhappy since commit d26fa4f went in, but I think
that just exposed a pre-existing bug. Running valgrind here
duplicates the failure:

==00:00:02:01.653 16626== Conditional jump or move depends on uninitialised value(s)
==00:00:02:01.653 16626== at 0x4BDF6B: btint4cmp (nbtcompare.c:97)
==00:00:02:01.653 16626== by 0x81D6BE: FunctionCall2Coll (fmgr.c:1318)
==00:00:02:01.653 16626== by 0x52D584: partition_bounds_equal (partition.c:627)
==00:00:02:01.653 16626== by 0x80CF8E: RelationClearRelation (relcache.c:1203)
==00:00:02:01.653 16626== by 0x80E601: RelationCacheInvalidateEntry (relcache.c:2662)
==00:00:02:01.653 16626== by 0x803DD6: LocalExecuteInvalidationMessage (inval.c:568)
==00:00:02:01.653 16626== by 0x803F53: ProcessInvalidationMessages.clone.0 (inval.c:444)
==00:00:02:01.653 16626== by 0x8040C8: CommandEndInvalidationMessages (inval.c:1056)
==00:00:02:01.653 16626== by 0x80C719: RelationSetNewRelfilenode (relcache.c:3490)
==00:00:02:01.653 16626== by 0x5CD50A: ExecuteTruncate (tablecmds.c:1393)
==00:00:02:01.653 16626== by 0x721AC7: standard_ProcessUtility (utility.c:532)
==00:00:02:01.653 16626== by 0x71D943: PortalRunUtility (pquery.c:1163)

IOW, partition_bounds_equal() is testing uninitialized memory during
a TRUNCATE on a partitioned table.

regards, tom lane