Re: Centralised architecture detection

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Lukas Fittl <lukas(at)fittl(dot)com>, John Naylor <johncnaylorls(at)gmail(dot)com>, Bryan Green <dbryan(dot)green(at)gmail(dot)com>
Subject: Re: Centralised architecture detection
Date: 2026-06-03 21:08:55
Message-ID: 3127341.1780520935@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Nathan Bossart reminded me of this thread after I'd independently
> rediscovered the same thing [1]. I agree with standardizing on
> just one spelling of these CPU-type macros. But I wonder why we
> should invent our own instead of standardizing on gcc's spellings
> (that is, __x86_64__ etc). The amount of code churn required for
> this patch would drop drastically if we did it that way. And I
> suspect it would be less likely that we'd need to fixup future patch
> submissions than if we have a homegrown standard.

Concretely, I'm imagining that we'd do more or less the attached in
c.h, and then the rest of the work would just be to remove the
not-very-large number of references to the alternative CPU symbols.

Note that I threw in an "#else #error" branch to ensure that we
successfully identify every architecture. Even if you don't like
this naming scheme, we should do that with the original patch too.

regards, tom lane

Attachment Content-Type Size
wip-standardize-macros-for-detecting-architectures.patch text/x-diff 2.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-06-03 21:17:31 Re: alert clients when prepared statements are deallocated
Previous Message Tom Lane 2026-06-03 20:23:03 Re: Broken build on macOS (Universal / Intel): cpuid instruction not available