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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql: Build src/port files as a library with -fPIC, and use that in li
Дата
Msg-id 20671.1538142538@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql: Build src/port files as a library with -fPIC, and usethat in li  (Christoph Berg <myon@debian.org>)
Ответы Re: pgsql: Build src/port files as a library with -fPIC, and usethat in li  (Christoph Berg <myon@debian.org>)
Список 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 по дате отправления:

Предыдущее
От: Christoph Berg
Дата:
Сообщение: Re: pgsql: Build src/port files as a library with -fPIC, and usethat in li
Следующее
От: Jesper Pedersen
Дата:
Сообщение: Re: executor relation handling