Re: Fix hashchar() and hashcharextended() to not depend on char signedness

On Thu, Jul 30, 2026 at 06:51:32AM +0000, Tristan Partin 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.
>
> Attached are three patches:
>
> 1. A series of tests to exercise the issue in a new TAP test and
> a regression test for the default path of
> `default_char_signedness = true`. The TAP test will show a failure.
> 2. A fix for the functions to ensure they produce the same results
> regardless of platform.
> 3. A consistency fix for charhashfast() such that it always produces the
> same value regardless of platform. This patch is kind of unimportant
> because the value is never persisted or sent to another process. I'll
> leave it up to the committer to pull the patch in or not.
>
> I am not sure that this can be backpatched before 19. I think it will
> cause queries to produce different values. Definitely good to fix before
> 19 is final though.
>
> [0]: https://www.postgresql.org/message-id/19587-4416a590531c9c73%40postgresql.org

Backpatch is out of the picture, but it also seems unwise to me to
change this computation on HEAD as well.

Assuming that this patch gets applied on HEAD, wouldn't that at least
break partitioned tables that are partitioned based on hash(char) once
a pre-v19 instance is upgraded to v20 with pg_upgrade, relying on a
new behavior which would be GUC-dependent?

I get the correctness argument, but the compatibility argument could
create quite some pain if pg_upgrade does not check for the existence
of such tables, at least, or other objects that rely on an on-disk
state that depend on the past behavior, these getting broken with the
new behavior if the GUC is incorrect flipped. Or am I missing
something obvious?
--
Michael