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

From Thomas Munro
Subject Re: Cleaning up historical portability baggage
Date
Msg-id CA+hUKGJdfTFtZXQ8P8CZtyx1k=mHcOD9savHVR2cjSSVp5Uirw@mail.gmail.com
Whole thread Raw
In response to Re: Cleaning up historical portability baggage  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Cleaning up historical portability baggage
Re: Cleaning up historical portability baggage
List pgsql-hackers
On Fri, Aug 12, 2022 at 7:15 PM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
> On 11.08.22 12:02, Thomas Munro wrote:
> >   * The concept of a no-Unix-socket build is removed.  We should be
> > able to do that now, right?  Peter E seemed to say approximately that
> > in the commit message for 797129e5.  Or is there a thought that a new
> > operating system might show up that doesn't have 'em and we'd wish
> > we'd kept this stuff well marked out?
>
> Most uses of HAVE_UNIX_SOCKETS are not useful independent of that
> question.  For example, you patch has
>
> @@ -348,7 +343,6 @@ StreamServerPort(int family, const char *hostName,
> unsigned short portNumber,
>         hint.ai_flags = AI_PASSIVE;
>         hint.ai_socktype = SOCK_STREAM;
>
> -#ifdef HAVE_UNIX_SOCKETS
>         if (family == AF_UNIX)
>         {
>                 /*
>
> But on a platform without support for Unix sockets, family just won't be
> AF_UNIX at run time, so there is no need to hide that if branch.

Good point.

> Note that we already require that AF_UNIX is defined on all platforms,
> even if the kernel doesn't support Unix sockets.

POSIX requires the macro too.  I think this would count as SUSv3 (AKA
issue 6?).  (IIUC it existed in much older POSIX form as 1g, it's all
very confusing...)

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_socket.h.html

> But maybe it would be better to make that a separate patch from the
> sys/un.h configure changes, just so there is more clarity around it.

Cool, I'll do that.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Cleaning up historical portability baggage
Next
From: Amit Kapila
Date:
Subject: Re: Introduce wait_for_subscription_sync for TAP tests