Re: Tom Lane 2019-01-31 <12792.1548965...@sss.pgh.pa.us>
> initdb hasn't depended on those libpq exports since 8.2, and it was
> a bug that it did so even then.
9.2 psql (and createuser, ...) is also broken:
/usr/lib/postgresql/9.2/bin/psql: symbol lookup error:
/usr/lib/postgresql/9.2/bin/psql:
On Thu, Jan 31, 2019 at 2:50 PM Tom Lane wrote:
> Robert Haas writes:
> > Isn't the issue more a matter of whether it's OK to break
> > compatibility without changing SO_*_VERSION?
>
> We're breaking compatibility only if you regard pqsignal() as
> part of the advertised API, which I don't.
Well
Robert Haas writes:
> On Thu, Jan 31, 2019 at 2:50 PM Tom Lane wrote:
>> We're breaking compatibility only if you regard pqsignal() as
>> part of the advertised API, which I don't.
> Well, I would agree with that if it weren't the case that binaries we
> ship apparently use that API. If we say
Robert Haas writes:
> On Tue, Jan 29, 2019 at 10:10 AM Tom Lane wrote:
>> Well, 8.2 is *very* long out of support, and there are plenty of
>> nasty bugs you're at risk of if you keep using it. So I don't
>> find this to be a good argument for contorting what we do in v12.
> Isn't the issue more
On Tue, Jan 29, 2019 at 10:10 AM Tom Lane wrote:
> Well, 8.2 is *very* long out of support, and there are plenty of
> nasty bugs you're at risk of if you keep using it. So I don't
> find this to be a good argument for contorting what we do in v12.
Isn't the issue more a matter of whether it's OK
Re: Tom Lane 2019-01-29 <27653.1548774...@sss.pgh.pa.us>
> > It took a while to notice, but this change does break 8.2's initdb if
> > libpq5 from PG12 is installed:
> > $ /usr/lib/postgresql/8.2/bin/initdb
> > /usr/lib/postgresql/8.2/bin/initdb: symbol lookup error:
> > /usr/lib/postgresql/8.2/bi
Christoph Berg writes:
> Re: Tom Lane 2018-09-28 <20671.1538142...@sss.pgh.pa.us>
>> I proposed in
>> https://www.postgresql.org/message-id/19581.1538077...@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_
Re: Tom Lane 2018-09-28 <20671.1538142...@sss.pgh.pa.us>
> >> I proposed in
> >> https://www.postgresql.org/message-id/19581.1538077...@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_encodi
Christoph Berg writes:
> Re: Tom Lane 2018-09-28 <19404.1538140...@sss.pgh.pa.us>
>> I proposed in
>> https://www.postgresql.org/message-id/19581.1538077...@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_ser
Re: Tom Lane 2018-09-28 <19404.1538140...@sss.pgh.pa.us>
> > Is this is a problem for libpq5 users?
>
> I proposed in
> https://www.postgresql.org/message-id/19581.1538077...@sss.pgh.pa.us
>
> that we should remove pqsignal, as well as
> pg_utf_mblen
> pg_encoding_to_char
> pg_char_to_encoding
>
Christoph Berg writes:
> Re: Tom Lane 2018-09-27
>> Build src/port files as a library with -fPIC, and use that in libpq.
> This made the "pqsignal" symbol disappear from libpq5.so:
Oh, interesting. I'd seen an actual error on prairiedog, but apparently
some other linkers just silently omit the
Re: Tom Lane 2018-09-27
> Build src/port files as a library with -fPIC, and use that in libpq.
This made the "pqsignal" symbol disappear from libpq5.so:
13:27:55 dpkg-gensymbols: error: some symbols or patterns disappeared in the
symbols file: see diff output below
13:27:55 dpkg-gensymbols: war
12 matches
Mail list logo
