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

From Tom Lane
Subject Re: pgsql: Build src/port files as a library with -fPIC, and use that in li
Date
Msg-id 20671.1538142538@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Build src/port files as a library with -fPIC, and usethat in li  (Christoph Berg <myon@debian.org>)
Responses Re: pgsql: Build src/port files as a library with -fPIC, and usethat in li
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: pgsql: Build src/port files as a library with -fPIC, and usethat in li
Next
From: Jesper Pedersen
Date:
Subject: Re: executor relation handling