> On 29 Sep 2022, at 23:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>>> On 29 Sep 2022, at 23:08, Tom Lane <tgl@sss.pgh.pa.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/