BUG #19587: hashchar (internal "char" type) depends on platform char signedness

The following bug has been logged on the website:

Bug reference: 19587
Logged by: Michael Malis
Email address: malis(at)pgrust(dot)com
PostgreSQL version: 18.4
Operating system: Linux x86_64 and Linux aarch64, same package build
Description:

This is about the internal single-byte "char" type (pg_type oid 18, the
one needing double quotes), not SQL CHAR(n), which is bpchar and is
unaffected.

hashchar() and hashcharextended() cast through a bare char, whose
signedness is implementation-defined:

hashchar(PG_FUNCTION_ARGS)
{ return hash_uint32((int32) PG_GETARG_CHAR(0)); }

DatumGetChar() returns char, so a high-bit byte sign-extends where
char is signed (x86-64, macOS) and does not where it is unsigned
(Linux aarch64). Other integer hash functions cast from explicitly-signed
types and are unaffected.

Reproduce (SQL_ASCII database, on each platform):

SELECT hashchar(chr(128)::"char");

x86-64: 1361043915 (= hashint4(-128))
aarch64: 1807103465 (= hashint4( 128))

Impact. Hash aggregation and hash joins are unaffected, since a query
hashes both sides with the same binary. The problem is where the hash is
persisted: hash partitioning on a "char" column routes rows differently
per platform, so a pg_dump taken on one architecture fails to restore on
the other (violates partition constraint; --load-via-partition-root
avoids it), and a hash index on such a column returns false negatives if
the data directory is read by a build with the opposite signedness.