Re: BUG #17625: In PG15 PQsslAttribute returns different values than PG14 when SSL is not in use for the connection

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #17625: In PG15 PQsslAttribute returns different values than PG14 when SSL is not in use for the connection
Дата
Msg-id 346263.1664480998@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #17625: In PG15 PQsslAttribute returns different values than PG14 when SSL is not in use for the connection  (PG Bug reporting form <noreply@postgresql.org>)
Ответы Re: BUG #17625: In PG15 PQsslAttribute returns different values than PG14 when SSL is not in use for the connection  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
PG Bug reporting form <noreply@postgresql.org> writes:
> According to the connection I am using, PQsslInUse is returning FALSE. 
> However, when I check the PQsslAttribute values, they are returning
> "OpenSSL, NULL, NULL, NULL, NULL".  In PostgreSQL 14, the library returns
> NULL when the connection is not using OpenSSL.

> It looks like commit ebc8b7d4416d8e0dfb7c05132ef6182fd3daf885 changed this
> behavior.

AFAICS that behavioral change is deliberate: for the single case
of inquiring about "library", PQsslAttribute now tells you which
SSL implementation libpq *can* use, not which one it's actually
using on a given connection.  I'm not sure that this is a great
definition, since it's so unlike the behavior for other attributes.
I can see the point of being able to check that, but should we
have invented a new function instead of overloading PQsslAttribute
this way?  One concrete point against this is that should we ever
be able to build libpq with the ability to use more than one GSS
library, this API would be utterly broken.

However, given that we're past rc1, I'm afraid that ship may have
sailed.  Assuming we leave it like this, how would you propose
changing the documentation to make it more clear?

            regards, tom lane



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Malay Keshav
Дата:
Сообщение: [Bug][Ver 11]: Generic query plan selected is worse than custom query plan
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [Bug][Ver 11]: Generic query plan selected is worse than custom query plan