> On 29 Sep 2022, at 22:16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
>> 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.
That was the intention of the patch, as different libraries may require
different connstrings there needs to be a way to know the library which will be
use when connecting.
> Actually, wait a minute: both the documentation and the commit
> message claim the new behavior is something different than what it
> actually is. The intention seems to have been to change the
> behavior only for the conn == NULL case. So maybe we need to
> fix it as attached.
Hrmpf, yes, I agree with your patch.
> This'd still be broken for the
> multiple-libraries scenario, but I admit that that's pretty
> hypothetical.
We can cross that bridge if get there, nothing here prevents the case in the
hypothetical future unless I'm missing something.
We still need to change the docs though, maybe along the lines of the below
(but with better wording):
- Name of the SSL implementation in use. (Currently, only
- <literal>"OpenSSL"</literal> is implemented)
+ Name of the implementation which will be used for connections
+ using SSL in case <literal>conn</literal> is NULL, or in case
+ <literal>conn</literal> is an SSL enabled connection. If
+ <literal>conn</literal> is a a non-SSL connection NULL is returned.
+ (Currently, only <literal>"OpenSSL"</literal> is implemented)
--
Daniel Gustafsson https://vmware.com/