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: <20180928132013.GE26142@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>
Comments: In-reply-to Christoph Berg <myon@debian.org>
	message dated "Fri, 28 Sep 2018 15:20:13 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <20670.1538142538.1@sss.pgh.pa.us>
Date: Fri, 28 Sep 2018 09:48:58 -0400
Message-ID: <20671.1538142538@sss.pgh.pa.us>
Precedence: bulk

Christoph Berg <myon@debian.org> writes:
> Re: Tom Lane 2018-09-28 <19404.1538140436@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?

> I'm fine with that if we say (a) should be true, and even if it is
> not, (b) is an easy workaround. Bumping the libpq SONAME just because
> of this seems excessive.

Yeah, if anyone insists that this requires a soname bump, I'd probably
look for another solution.  Making the makefiles a bit cleaner is not
worth the churn that would cause, IMO.

The place where we'd probably end up if anyone's unhappy about this
is that we'd still be symlinking the three files pqsignal.c, wchar.c,
and encnames.c into libpq.  That's not very desirable, but at least
it'd be a fixed list rather than something we're continually having
to change.

			regards, tom lane