From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Let's stop with the retail rebuilds of src/port/ files already
Date: Fri, 28 Sep 2018 14:59:58 -0400
Message-ID: <13983.1538161198@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, pgsql-hackers@lists.postgresql.org
Subject: Re: Let's stop with the retail rebuilds of src/port/ files already
In-Reply-To: <13983.1538161198@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox