Re: disallow big-endian on aarch64

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

In response to

Responses

Browse pgsql-hackers by date

  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