From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, pgsql-hackers(at)postgresql(dot)org, andres(at)anarazel(dot)de |
Subject: | Re: disallow big-endian on aarch64 |
Date: | 2025-10-02 21:31:48 |
Message-ID: | aN7vRDeXLULIhv3l@nathan |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 02, 2025 at 05:08:42PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
>> The benefit is that we can safely assume little-endian in AAarch64-specific
>> code, and on the off-chance that someone tries to build Postgres in an
>> AArch64/big-endian environment, we aren't pretending to support it.
>
> Is that actually a meaningful benefit, ie can we remove any code
> anywhere?
I'm not aware of existing code that is broken, but some of the stuff I'm
intending to commit soon to optimize hex_{encode,decode} might be sensitive
to endianness. In any case, I don't think it's outside the realm of
possibilities for architecture-specific code.
> Given that we don't believe any OS support exists for this
> combination, I'm not sure why we should expend configure cycles
> on rejecting it. If anyone ever builds such a platform and tries
> to run Postgres on it, either it will work or they'll have to start
> writing patches. But that applies to a whole lot of not-actively-
> tested configurations. I don't see why we should go out of our
> way to reject this one.
Okay.
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2025-10-02 22:24:45 | Re: Teaching planner to short-circuit empty UNION/EXCEPT/INTERSECT inputs |
Previous Message | Daniel Gustafsson | 2025-10-02 21:15:15 | Re: [PATCH] Add tests for Bitmapset |