Re: Cleaning up historical portability baggage

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.

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.

> I tried to figure out how to get rid of
> PGAC_STRUCT_SOCKADDR_STORAGE_MEMBERS, but there we're into genuine
> non-standard cross-platform differences.

Right. I don't think it's worth sweating over.

regards, tom lane