Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oMvYF-0007xy-J7 for pgsql-hackers@arkaria.postgresql.org; Sat, 13 Aug 2022 18:07:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oMvYE-0005dc-5o for pgsql-hackers@arkaria.postgresql.org; Sat, 13 Aug 2022 18:07:58 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oMvYD-0005dP-SD for pgsql-hackers@lists.postgresql.org; Sat, 13 Aug 2022 18:07:57 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oMvY4-0003RX-Jk for pgsql-hackers@postgresql.org; Sat, 13 Aug 2022 18:07:53 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 27DI7eDe360949; Sat, 13 Aug 2022 14:07:40 -0400 From: Tom Lane To: Thomas Munro cc: Peter Eisentraut , Andres Freund , Andrew Dunstan , Robert Haas , pgsql-hackers Subject: Re: Cleaning up historical portability baggage In-reply-to: References: <20220712173352.trdeq66asbv6vf2q@awork3.anarazel.de> <1662559.1657648462@sss.pgh.pa.us> <1249825.1658622186@sss.pgh.pa.us> <20220804034343.unm4rdynedbigamv@awork3.anarazel.de> <3322724.1659586159@sss.pgh.pa.us> <295419.1659918447@sss.pgh.pa.us> <747620.1660002360@sss.pgh.pa.us> <81bb50c! a-d0ea-8cb2-7453-a5058a7b49a8@enterprisedb.com> Comments: In-reply-to Thomas Munro message dated "Sun, 14 Aug 2022 00:23:02 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <360947.1660414060.1@sss.pgh.pa.us> Date: Sat, 13 Aug 2022 14:07:40 -0400 Message-ID: <360948.1660414060@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thomas Munro 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