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. > We could also add a new API (say, PQsslLibrary()) but I don't know if > that gives us anything in practice. Thoughts? Knowing that the GSSAPI stuff is part of fe-secure.c, we may want instead a call that returns a list of supported secure libraries. -- Michael
signature.asc
Description: PGP signature
