Re: Cleaning up historical portability baggage - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Cleaning up historical portability baggage
Date
Msg-id 360948.1660414060@sss.pgh.pa.us
Whole thread Raw
In response to Re: Cleaning up historical portability baggage  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Cleaning up historical portability baggage
Re: Cleaning up historical portability baggage
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.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



pgsql-hackers by date:

Previous
From: Ajin Cherian
Date:
Subject: Re: Support logical replication of DDLs
Next
From: Justin Pryzby
Date:
Subject: Re: [patch]HashJoin crash