Hi On Wed, Nov 24, 2021 at 9:12 AM Hans Buschmann <buschm...@nidsa.net> wrote:
> Hello Michael, > > thanks for your hard work and quick response! > It is very convenient to only use VS2022 for Windows from now on... > > >Diff unrelated to your patch. > > Sorry for the copysoft problem from the first version. > > >Glad to see that we should have nothing to do about locales this > >time. I have not tested, but I think that you covering all the areas > >that need a refresh here. Nice work. > > I think it is almost impossible to overestimate the value of such support > from experienced hackers to others starting their journey right now... > > I hope I can motivate you (and other experienced hackers) to give me some > more support on my real project arriving anytime soon. It addresses > hex_encoding (and more) targetting mostly pg_dump, but requires also some > deeper knowledge of general infrastructure and building (also on Windows). > Stay tuned! > > PS: Does anybody have good relations to EDB suggesting them to target > VS2022 as the build environment for the upcoming PG15 release? > That would be me... > > postgres=# select version (); > version > ------------------------------------------------------------ > PostgreSQL 14.1, compiled by Visual C++ build 1931, 64-bit > (1 row) > It's extremely unlikely that we'd shift to such a new version for PG15. We build many components aside from PostgreSQL, and need to use the same toolchain for all of them (we've had very painful experiences with mix n match CRT versions in the past) so it's not just PG that needs to support VS2022 as far as we're concerned - Perl, Python, TCL, MIT Kerberos, OpenSSL, libxml2, libxslt etc. are all built with the same toolchain for consistency. -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com
