> On 18 Aug 2021, at 02:32, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, Aug 18, 2021 at 12:06:59AM +0000, Jacob Champion wrote:
>> I have a local test suite that I've been writing against libpq. With
>> the new ssldatabase connection option, one tricky aspect is figuring
>> out whether it's supported or not. It doesn't look like there's any way
>> to tell, from a client application, whether NSS or OpenSSL (or neither)
>> is in use.
>
> That's about guessing which library libpq is compiled with, so yes
> that's a problem.
>
>> so that you don't have to have an actual connection first in order to
>> figure out what connection options you need to supply. Clients that
>> support multiple libpq versions would need to know whether that call is
>> reliable (older versions of libpq will always return NULL, whether SSL
>> is compiled in or not), so maybe we could add a feature macro at the
>> same time?
>
> Still, the problem is wider than that, no? One cannot know either if
> a version of libpq is able to work with GSSAPI until they attempt a
> connection with gssencmode. It seems to me that we should work on the
> larger picture here.
I think we should do both. PQsslAttribute() already exists, and being able to
get the library attribute for NULL conn object when there are multiple
libraries makes a lot of sense to me. That doesn’t exclude working on a better
way for apps to interrogate the libpq they have at hand for which capabilities
it has. Personally I’m not sure what that API could look like, but we should
discuss that in a separate thread I guess.
--
Daniel Gustafsson https://vmware.com/