Re: Unix-domain socket support on Windows

Here is another patch set to enable this functionality.

0001 enables Unix-domain sockets on Windows, but leaves them turned off 
by default at run time, using the mechanism introduced by a9cff89f7e. 
This is relatively straightforward, except perhaps some aesthetic 
questions about how these different configuration bits are distributed 
around the various files.

0002 deals with pg_upgrade.  It preserves the existing behavior of not 
using Unix-domain sockets on Windows.  This could perhaps be enhanced 
later by either adding a command-line option or a run-time test.  It's 
too complicated right now.

0003 deals with how initdb should initialize postgresql.conf and 
pg_hba.conf.  It introduces a run-time test similar to how we detect 
presence of IPv6.  After I wrote this patch, I have come to think that 
this is overkill and we should just always leave the "local" line in 
pg_hba.conf even if there is no run-time support in the OS.  (I think 
the reason we do the run-time test for IPv6 is that we need it to parse 
the IPv6 addresses in pg_hba.conf, but there is no analogous requirement 
for Unix-domain sockets.)  This patch is optional in any case.

0004 fixes a bug in the pg_upgrade test.sh script that was exposed by 
these changes.

0005 fixes up some issues in the test suites.  Right now, the TAP tests 
are hardcoded to not use Unix-domain sockets on Windows, where as 
pg_regress keys off HAVE_UNIX_SOCKETS, which is no longer a useful 
distinguisher.  The change is to not use Unix-domain sockets for all the 
tests by default on Windows (the previous behavior) but give an option 
to use them.  At the moment, I would consider running the test suites 
with Unix-domain sockets enabled as experimental, but that's only 
because of various issues in the test setups.  For instance, there is an 
issue in the comment of pg_regress.c remove_temp() that I'm not sure how 
to address.  Also, the TAP tests don't seem to work because of some path 
issues.  I figured I'd call time on fiddling with this for now and ship 
the patches.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services