Re: pgsql: Build src/port files as a library with -fPIC, and usethat in li
От | Christoph Berg |
---|---|
Тема | Re: pgsql: Build src/port files as a library with -fPIC, and usethat in li |
Дата | |
Msg-id | 20180928132013.GE26142@msg.df7cb.de обсуждение исходный текст |
Ответ на | Re: pgsql: Build src/port files as a library with -fPIC, and use that in li (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Build src/port files as a library with -fPIC, and use that in li
|
Список | pgsql-hackers |
Re: Tom Lane 2018-09-28 <19404.1538140436@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: