I've been having issues with PostgreSQL error handling mostly on windows 64-bit using binaries I build with mingw64 and using under VC++ built PostgreSQL. Most of which I don't understand. As many have pointed out these issues MIGHT go away or be easier to debug if PostGIS was built with same tool chain as EDB VC++ distributions. I can't argue with that especially since its never been done.
The good news is changing my build chain from mingw64 GCC 4.5.4 to mingw64 GCC 4.8.0 has eradicated all of these issues,
and even ones I had with PL/V8 that happended both in a pure mingw64(w32/w64) as well as PostgreSQL VCC (32/64 bit) environment. It did
introduce this minor annoying nat, presumably because my libpq.dll now has a dependency on user32.dll (which just seems wrong). The other nat is that all the binaries I built that have c++ in them (depend on libstd++) now need to be recompiled which means my prior builds of PostGIS will not be compatible with my upcoming 4.8.0 ones. A real pain since for PostGIS/pgRouting I've got like at least 15 of those dependencies and growing. So I've decided to perform this exercise just for PostgreSQL 9.3 -- a new beginning at PostGIS 2.1 and see how it goes
before I bother with 9.2, 9.1. These issues really only affect PostgreSQL 64-bit PostGIS users and as a 64-bit user, you may never have even come across them.
PostGIS moving to CMake
As some people know, PostGIS DOES NOT YET support compiling in a pure VC++ environment, though we hope to in PostGIS 2.2 or 2.3 series when we hope to start
supporting CMake as our standard as ticketed here. I blame this on lack of people wanting to put the effort where their mouth is and my not pressuring because I prefer mingw64 as a build environment which works fine with a posix environment such as msys. If you really want to see VC++ supported as a build environment for PostGIS you should really start paying attention to this development and, instead of whining, roll up your sleeves, line up test/work out the kinks, and prove that YOU a VC++ developer really want this bad enough to work for it. I suspect I won't have the energy or knowledge to help out much with VC++. I suspect it will be a long and painful journey but one we have to travel to better cater to all community of developers. I plan to still stay in my little mingw64 camp though (I will do my part of trying to build PostGIS fully with CMake).
The need for cross tool support
A lot of what makes PostgreSQL
special is its extendable run-time architecture and what makes it especially special to me is I can build my extensions (even an extension as huge as PostGIS) with my tool of choice (mingw64) and plug it right into PostgreSQL VC++ built by someone else and it for the most part just works. THAT IS DARN AWESOME and I would hope this coolness does not go away. The parts that don't work (usually involve C++ code) are well an inconvenience, but I still prefer suffering this over being stuck building everything myself or requiring others to eat my preferred dogfood or changing my dogfood. The big wrinkle is trying to debug these things in a mix of environments and that I admit is challenging but hope doable and hope something that others besides me are interested in doing.