On 27 January 2016 at 20:54, Alvaro Herrera <alvhe...@2ndquadrant.com>

> > 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

> 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.
Yeah, strongly agree there.

CMake has excellent MSVC support btw.

 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Reply via email to