Re: pgsql: Build src/port files as a library with -fPIC, and use that in li

From: Christoph Berg <myon(at)debian(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql: Build src/port files as a library with -fPIC, and use that in li
Date: 2018-09-28 13:20:13
Message-ID: 20180928132013.GE26142@msg.df7cb.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Re: Tom Lane 2018-09-28 <19404(dot)1538140436(at)sss(dot)pgh(dot)pa(dot)us>
> > Is this is a problem for libpq5 users?
>
> 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.

On the Debian side, I can simply remove the symbol from the tracking
file and the buildsystem will be happy again.

Christoph

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2018-09-28 13:48:58 Re: pgsql: Build src/port files as a library with -fPIC, and use that in li
Previous Message Tom Lane 2018-09-28 13:13:56 Re: pgsql: Build src/port files as a library with -fPIC, and use that in li

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-09-28 13:48:58 Re: pgsql: Build src/port files as a library with -fPIC, and use that in li
Previous Message Tom Lane 2018-09-28 13:13:56 Re: pgsql: Build src/port files as a library with -fPIC, and use that in li