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
|
Список | 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 по дате отправления: