On Mon, Mar 23, 2026, at 7:57 AM, Peter Eisentraut wrote: > On 21.03.26 19:39, Greg Burd wrote: >> I think that $subject is interesting because it presents an opportunity to >> reduce the code we maintain and potentially improve performance. This >> thread has languished a bit on the list, so I picked it up. I've tried it >> out on my local systems (greenfly, unicorn, icarus, macOS, and a Fedora >> x86_64 laptop I use as my daily driver) using clang, gcc, and MSVC. It >> seems to work, I still need to measure performance. >> >> tested: >> - Linux x86_64 (GCC 14.3.0) >> - Linux RISC-V (GCC 13.3.0, Clang 20.1.2) >> - FreeBSD x86_64 (Clang 19.1.7) >> - Windows ARM64 (MSVC 2022) >> >> I realize we're close to the end of the v19 cycle, but one last look >> couldn't hurt could it? Attached is "v3" of his patch set. Is anyone else >> interested in this? :) > > 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'm not a Microsoft marketplace or tools expert, so I can't gauge how hard it is to require 2022 or if that'd impact too many users of PG today on that platform who choose to use MSVC over gcc or clang. I have even less insight into what Azure uses for the host OS (Linux, FreeBSD or Windows) running Postgres for their services, but lets say it's Windows and they have a requirement for MSVC when compiling. I'd bet they could switch to 2022 without too much trouble. Are there others out there that deploy/depend/use PG on Windows and have a strong bias for MSVC (vs clang or gcc)? I have no idea. > Maybe a bit late for that. It is late, and this isn't a small set of changes. I'd be curious to know if, other than the buildfarm animals that are Wnidows with MSVC < 2022, the rest would work with this change or not. I'd also like to get some objective data on performance. Would it be wasted effort for me to get this patch into a form that could be committed, tested on the farm, then rolled back if needed (a single patch)? Is that even a thing we'd consider trying out? Maybe the effort is worth it and we consider this again at the start of v20 development? best. -greg
