syntax apparently does not work for all toolchains on that platform.
Per Honda Shigehiro.

request packet, use pqReadData().  This has the same effect since
conn->ssl isn't set yet and we aren't expecting more than one byte.
The advantage is that we will correctly detect loss-of-connection
instead of going into an infinite loop.  Per report from Hannu Krosing.

discussion on pgsql-hackers-win32 list.  Documentation still needs to
be tweaked --- I'm not sure how to refer to the APPDATA folder in
user documentation.

consistent.  On Unix we now always consult getpwuid(); $HOME isn't used
at all.  On Windows the code currently consults $USERPROFILE, or $HOME
if that's not defined, but I expect this will change as soon as the win32
hackers come to a consensus.  Nothing done yet about changing the file
names used underneath $USERPROFILE.

subroutine that can hide platform dependencies.  The WIN32 path is still
a stub, but I await a fix from one of the win32 hackers.
Also clean up unnecessary #ifdef WIN32 ugliness in a couple of places.

Michael Fuhr.

dangling cross-references.

< * Allow building with directories containing spaces
> * Allow building in directories containing spaces
<   There are two capabilities here, first the ability to build from a
<   source directory that contains spaces, and second the ability to install
<   into a directory that contains spaces.  The first is probably not
<   possible because 'gmake' and other compiler tools do not fully support
<   spaces in path names.  The second is possible with proper quoting in
<   the makefiles.  Because PostgreSQL supports relocatable installs, it
<   is possible to install into a directory that doesn't contain spaces and
<   then copy the install to a directory with spaces.
>   This is probably not possible because 'gmake' and other compiler tools
>   do not fully support quoting of paths with spaces.
>
> * Allow installing to directories containing spaces
>
>   This is possible if proper quoting is added to the makefiles for the
>   install targets.  Because PostgreSQL supports relocatable installs, it
>   is already possible to install into a directory that doesn't contain
>   spaces and then copy the install to a directory with spaces.

>   There are two capabilities here, first the ability to build from a
>   source directory that contains spaces, and second the ability to install
>   into a directory that contains spaces.  The first is probably not
>   possible because 'gmake' and other compiler tools do not fully support
>   spaces in path names.  The second is possible with proper quoting in
>   the makefiles.  Because PostgreSQL supports relocatable installs, it
>   is possible to install into a directory that doesn't contain spaces and
>   then copy the install to a directory with spaces.

 Viktor Vislobokov

share lock on a buffer being written out before releasing BufMgrLock in
the BufferAlloc code path; if we do it later we might block on someone
who's re-pinned the buffer.  I believe this is only an issue for BufferAlloc
and not the other places that call FlushBuffer.  BufferSync must continue
to do it the old way since it may well be trying to write buffers that
other backends have pinned; but it should not be holding any conflicting
locks.  FlushRelationBuffers is okay since it's got exclusive lock at the
relation level.

> * Allow building with directories containing spaces