From: Tom Lane <tgl@sss.pgh.pa.us>
To: Christoph Berg <myon@debian.org>
cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: pgsql: Build src/port files as a library with -fPIC,
 and use that in li
In-reply-to: <20190129140437.GF9860@msg.df7cb.de>
References: <E1g5Y8r-0006vs-QA@gemulon.postgresql.org>
 <20180928115830.GC26142@msg.df7cb.de> <19404.1538140436@sss.pgh.pa.us>
 <20180928132013.GE26142@msg.df7cb.de> <20671.1538142538@sss.pgh.pa.us>
 <20190129140437.GF9860@msg.df7cb.de>
Comments: In-reply-to Christoph Berg <myon@debian.org>
	message dated "Tue, 29 Jan 2019 15:04:38 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <27652.1548774621.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 29 Jan 2019 10:10:21 -0500
Message-ID: <27653.1548774621@sss.pgh.pa.us>
Precedence: bulk

Christoph Berg <myon@debian.org> writes:
> Re: Tom Lane 2018-09-28 <20671.1538142538@sss.pgh.pa.us>
>> I proposed in
>> https://www.postgresql.org/message-id/19581.1538077716@sss.pgh.pa.us
>> that we should remove pqsignal, as well as
>> pg_utf_mblen
>> pg_encoding_to_char
>> pg_char_to_encoding
>> pg_valid_server_encoding
>> pg_valid_server_encoding_id
>> =

>> from libpq's exports, on the grounds that (a) nobody should be using
>> those (they're undocumented as exports), and (b) anybody who is using
>> them should get them from libpgport/libpgcommon instead.  Thoughts?

> It took a while to notice, but this change does break 8.2's initdb if
> libpq5 from PG12 is installed:
> $ /usr/lib/postgresql/8.2/bin/initdb
> /usr/lib/postgresql/8.2/bin/initdb: symbol lookup error: /usr/lib/postgr=
esql/8.2/bin/initdb: undefined symbol: pqsignal

Well, 8.2 is *very* long out of support, and there are plenty of
nasty bugs you're at risk of if you keep using it.  So I don't
find this to be a good argument for contorting what we do in v12.

If you really want to keep using 8.2 (and even make new installations
with it!?), you could back-patch the 8.3 patch that made sure that
initdb didn't absorb pqsignal, pg_encoding_to_char, etc from libpq.
It looks like what you'd need is a portion of the Makefile changes
from 8468146b03c87f86162cee62e0de25f6e2d24b56.

BTW, I noticed this in that patch's commit message:

    Going forward, we want to fix things so that encoding IDs can be chang=
ed
    without an ABI break, and this commit includes the changes needed to a=
llow
    libpq's encoding IDs to be treated as fully independent of the backend=
's.
    The main issue is that libpq clients should not include pg_wchar.h or
    otherwise assume they know the specific values of libpq's encoding IDs=
,
    since they might encounter version skew between pg_wchar.h and the lib=
pq.so
    they are using.  To fix, have libpq officially export functions needed=
 for
    encoding name<=3D>ID conversion and validity checking; it was doing th=
is
    anyway unofficially.

So it was wrong of me to propose moving pg_encoding_to_char() et al
into libpgcommon: doing so would've re-introduced the hazard of
client code misinterpreting the encoding IDs returned by
PQclientEncoding() (and how the heck did I miss that libpq.sgml
does document that function for exactly that purpose?).

Fortunately, I didn't do that ...

			regards, tom lane