Re: Centralised architecture detection
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andres Freund <andres@anarazel.de>, Lukas Fittl <lukas@fittl.com>, John Naylor <johncnaylorls@gmail.com>, Bryan Green <dbryan.green@gmail.com>
Date: 2026-06-03T21:08:55Z
Lists: pgsql-hackers
Attachments
- wip-standardize-macros-for-detecting-architectures.patch (text/x-diff) patch
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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix CPU-identification macros for RISC-V.
- d3223485546e master landed
-
Clean up inconsistencies in CPU-identification macros.
- 2ef57e636fc9 master landed