| From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
|---|---|
| To: | Tristan Partin <tristan(at)partin(dot)io> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, malis(at)pgrust(dot)com |
| Subject: | Re: Fix hashchar() and hashcharextended() to not depend on char signedness |
| Date: | 2026-07-30 12:41:26 |
| Message-ID: | CAEze2Wh+ihWSxgRire=j774ThqfQqpWaX5bX3MzX5fg48-Wpbw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 30 Jul 2026 at 08:51, Tristan Partin <tristan(at)partin(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shlok Kyal | 2026-07-30 12:47:33 | Re: Support EXCEPT for ALL SEQUENCES publications |
| Previous Message | Vladlen Popolitov | 2026-07-30 12:31:31 | zic: fix PostgreSQL build failure on filesystems without hard link support |