Re: Cleaning up historical portability baggage

On Sun, Aug 14, 2022 at 6:07 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > I pushed these, except I chopped out the HAVE_UNIX_SOCKETS part as
> > requested. Here it is in a separate patch, with a commit message that
> > explains the rationale (essentially, what you said, it's basically a
> > runtime matter for a hypothetical AF_UNIX-less system to complain
> > about). Tom, does this argument persuade you?
>
> I looked more closely and saw that basically what HAVE_UNIX_SOCKETS
> is guarding is code that assumes the existence of AF_UNIX and
> struct sockaddr_un. As Peter said, we already rely on AF_UNIX
> in some other places; and I see that sys/un.h is required to exist
> and to define struct sockaddr_un as far back as SUSv2. So it
> does seem like the worst consequence is that we'd be compiling
> some code that would be unreachable on platforms lacking support.
> Objection withdrawn.

Thanks, and pushed with a couple of minor doc tweaks.

I hadn't paid attention to our existing abstract Unix socket support
before and now I'm curious: do we have a confirmed sighting of that
working on Windows? The thread didn't say so[1], and I'm suspicious
because I couldn't get simple standalone programs that bind() to
"\000c:\\xxx" to work sanely (but my method for investigating Windows
is to send the punch cards over to the CI system and wait for the
results to arrive by carrier pigeon which is cumbersome enough that I
haven't tried very hard). Naively shoving a @ into PostreSQL's
PG_REGRESS_SOCK_DIR also breaks CI.

> As for the other two, they look like nice cleanup if we can actually
> get away with it. I agree that the business about nonstandard libbind
> is not of interest anymore, but I have no idea about the state of
> play on Windows. I guess we can push 'em and see what the buildfarm
> thinks.

All green on CI... Next stop, build farm.

I'm a bit confused about why I had to #define gai_sterror
gai_strerrorA myself to get this working (my non-Windows-guy
understanding is that the A-for-ANSI [sic] variants of system
functions should be selected automatically unless you #define UNICODE
to get W-for-wide variants). If anyone has any clues about that, I'd
be glad to clean it up.

I *guess* the main risk here is that different error messages might
show up in some scenarios on Windows (everything else was already
going directly to OS functions on Windows 8.1+ if I'm reading the code
right), but surely that'd be progress -- messages from the real netdb
implementation are surely preferable to our fallback stuff.

[1] https://www.postgresql.org/message-id/flat/6dee8574-b0ad-fc49-9c8c-2edc796f0033%402ndquadrant.com