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

On Wed Jul 29, 2026 at 1:13 PM CDT, PG Bug reporting form wrote:

The following bug has been logged on the website:

Bug reference: 19587
Logged by: Michael Malis
Email address: malis@pgrust.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.

Hey Michael,

Thanks for the bug report. I sent a patch[0]/messages/by-id/DKBPGEV4AVNC.BRP938ZSVC2L@partin.io to -hackers for review that
should fix this in 19 and above.

[0]: /messages/by-id/DKBPGEV4AVNC.BRP938ZSVC2L@partin.io

--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)