Re: Fix hashchar() and hashcharextended() to not depend on char signedness - Mailing list pgsql-hackers

From Matthias van de Meent
Subject Re: Fix hashchar() and hashcharextended() to not depend on char signedness
Date
Msg-id CAEze2Wh+ihWSxgRire=j774ThqfQqpWaX5bX3MzX5fg48-Wpbw@mail.gmail.com
Whole thread
Responses Re: Support EXCEPT for TABLES IN SCHEMA publications
Re: Support EXCEPT for TABLES IN SCHEMA publications
List pgsql-hackers
On Thu, 30 Jul 2026 at 08:51, Tristan Partin <tristan@partin.io> wrote:
>
> In bug #19587[0], the user reported that hashchar() and
> hashcharextended() were not producing the same results for the same
> input because of sign extension depending on the platform.

This reminds me of [0], which saw the same difference in behaviour
cause discrepancies in indexing behaviour when replicating across
different architectures. That eventually led to a set of commits [1]
that landed with PG18 that includes tracking the signedness of char in
the control file, which turned this char-signedness incompatibility
explicit.

So, I don't think we guarantee the output of all 'immutable' functions
to have no changes in output when the system is compiled on different
platforms or with different settings. Collations are one example where
the platform may change their output, char-signedness during
compilation is another.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)

[0] https://www.postgresql.org/message-id/CB11ADBC-0C3F-4FE0-A678-666EE80CBB07@amazon.com
[1] 30666d1857, a8238f87f9, 1aab680591, and dfd8e6c73e



Attachment

pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Support for 8-byte TOAST values, round two
Next
From: Tom Lane
Date:
Subject: Re: Fix var_eq_const: sum selectivity of all matching MCV entries instead of stopping at first match