> If so many problems with MSVC can discard his support of Postgres?
I strongly disagree. MSVC is a high quality compiler and the primary tool for the platform. Yes, it's behind on standards support and that's annoying - OTOH MinGW relies on reverse-engineered headers, an old gcc fork, and has had some pretty nasty bugs.
It's a bit like saying we should drop gcc support on Linux and use icc or clang because it's more convenient for us.
Every platform has warts. We're just more used to ignoring warts on !windows.
That doesn't sound likely. Keep in mind that users might want to compile extension modules, and not everyone is going to use mingw for that. As far as I know, stuff compiled with MSVC is not compatible with mingw compiled objects. So even if the main packages switched to compiling with mingw, we'd probably still want to support MSVC.
They are compatible. You can use mingw modules in a MSVC-built postgres. The other way around should work too.
The main reason why is that on Windows you are expected to be very careful about your C library, always free()ing memory in the same module (DLL/EXE) you malloc() it in. Same rules with file handles, etc. This is required to work correctly with modules compiled with a mix of MSVC versions or mix of debug and release MSVC runtimes. The same principle applies to MinGW.
> Under windows we can use MinGW64/Msys or LLVM/Clang for MSVC.
I'm guessing that LLVM/Clang port would be useful for something, but I'm not clear what.
Are we moving forward with the CMake stuff? It would be *awesome* to get rid of the MSVC build scripts, and perhaps we can move forward on some smaller items such as PGDLLEXPORT markings as well.
