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

> On 29 Sep 2022, at 23:58, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>>> On 29 Sep 2022, at 23:08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> A definition that'd be consistent with what we just agreed to for
>>> PQsslAttribute is:
>>> PQsslAttributeNames(NULL): the attributes for the default SSL library,
>>> or an empty list if there is none.
>>> PQsslAttributeNames(conn): the attributes for the SSL library in use
>>> on this connection, or an empty list if not encrypted.
>
>> I think that makes sense, it keeps the API consistent.
>
> So more or less as attached, then.

LGTM.

- Returns an array of SSL attribute names available.
+ Returns an array of SSL attribute names that can be used
+ in <function>PQsslAttribute()</function>.

Maybe hairsplitting, but should we note that it can be used in PQsslAttribute()
for the conn which was passed as param to PQsslAttributeNames()? In a (still
hypothetical) multi-library case there is no guarantee that it will be valid
for another conn.

> Since this is mostly about future-proofing, I'd personally be content
> to put it in HEAD. Is there a case for shoehorning this into
> v15 at this late date? Consistency with PQsslAttribute would be
> good, but I'm not sure we want to make this kind of change post-RC1.

I'd be fine just doing this in HEAD.

--
Daniel Gustafsson https://vmware.com/