Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5xzk-0002zr-UL for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Sep 2018 19:00:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g5xzi-0004fx-5J for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Sep 2018 19:00:06 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5xzh-0004fo-Qu for pgsql-hackers@lists.postgresql.org; Fri, 28 Sep 2018 19:00:05 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5xzf-0005gv-91 for pgsql-hackers@lists.postgresql.org; Fri, 28 Sep 2018 19:00:04 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w8SIxwDc013984; Fri, 28 Sep 2018 14:59:58 -0400 From: Tom Lane To: Andres Freund cc: pgsql-hackers@lists.postgresql.org Subject: Re: Let's stop with the retail rebuilds of src/port/ files already In-reply-to: <19581.1538077716@sss.pgh.pa.us> References: <13022.1538003440@sss.pgh.pa.us> <20180926231331.pngbiyqaawrxgnwf@alap3.anarazel.de> <6570.1538020985@sss.pgh.pa.us> <19581.1538077716@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Thu, 27 Sep 2018 15:48:36 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13982.1538161198.1@sss.pgh.pa.us> Date: Fri, 28 Sep 2018 14:59:58 -0400 Message-ID: <13983.1538161198@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I wrote: > Now, if we go forward with that solution, there will be issues with > some other things that libpq exports without having defined itself: > src/backend/utils/mb/wchar.c: > pg_utf_mblen > src/backend/utils/mb/encnames.c: > pg_encoding_to_char > pg_char_to_encoding > pg_valid_server_encoding > pg_valid_server_encoding_id > What I was thinking of proposing was to move those two files out of the > backend and into src/common/, thereby normalizing their status as > modules available in both frontend and backend, and removing the need > for a special build rule for them in libpq. (initdb could be simplified > too.) Per this discovery, we'd need to also remove these symbols from > libpq's exports list, meaning that clients *must* get them from -lpgcommon > not from libpq. After further study I've concluded that moving those two files would be more neatnik-ism than is justified. While it'd get rid of the symlink-a-source-file technique in libpq, there'd still be other occurrences of that in our tree, so the actual cleanup benefit seems pretty limited. And while I'm prepared to believe that nobody outside PG uses pqsignal() or should do so, it's a little harder to make that case for the encnames.c functions; so the risk of causing problems seems noticeably greater. Accordingly, I cleaned up the usage of the existing src/common/ files but didn't move anything around. I plan to stop here unless the buildfarm shows more issues. regards, tom lane