"Greg Burd" <greg@burd.me> writes:
> On Mon, Mar 23, 2026, at 7:57 AM, Peter Eisentraut wrote:
>> We currently require MSVC 2019, so before this could be accepted, this
>> requirement would need to be adjusted (including documentation,
>> buildfarm updates, etc.).
> Fair point, it does seem that's the minimum supported version (2022).
I don't really see why we'd need to do that? I would expect any such
patch to cope gracefully with the lack of <stdatomic.h>, so it could
continue to support older MSVC by falling back to the older code
paths. For MSVC in particular, we'd not even need to maintain the
older code paths for arches other than x86 and ARM.
But even disregarding Windows, I'd look with great suspicion on a
patch that proposes to rip out all that handwritten code in favor of
requiring <stdatomic.h>. That'd be putting a great deal of trust in
code that's not under our control and frankly we have no reason to
trust yet, especially not from the standpoint of performance rather
than just minimum functionality. Note that the thread title is
"Trying out <stdatomic.h>", not "We're marrying <stdatomic.h>
sight-unseen, and there will be no divorce". So I want to see a
patch that treats <stdatomic.h> as an alternative implementation,
not The Only Way.
As for timing, this is the sort of patch that we usually feel should
go in near the start of a dev cycle, not near the end. So I counsel
making sure that it's in shape for commit early in v20, but not
expecting that it will get in now, even temporarily. There are too
many irons in the fire at this phase of the cycle, and too little
room to disambiguate "Greg broke it" from "somebody else broke it".
regards, tom lane
