| From: | Nico Williams <nico(at)cryptonector(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, 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:21:14 |
| Message-ID: | aiCayoqVfvLDM9bO@ubby |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 03, 2026 at 05:08:55PM -0400, Tom Lane wrote:
> 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.
Can a pre-processor make it an error for users to define __ macros?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2026-06-03 21:23:30 | Re: BackgroundPsql swallowing errors on windows |
| Previous Message | Nathan Bossart | 2026-06-03 21:17:31 | Re: alert clients when prepared statements are deallocated |