Re: Support for NSS as a libpq TLS backend - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: Support for NSS as a libpq TLS backend
Date
Msg-id 05da9d530ab01e6959bd50c993d590ad73575c21.camel@vmware.com
Whole thread Raw
In response to Re: Support for NSS as a libpq TLS backend  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Support for NSS as a libpq TLS backend  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Wed, 2021-03-24 at 09:28 +0900, Michael Paquier wrote:
> On Wed, Mar 24, 2021 at 12:05:35AM +0000, Jacob Champion wrote:
> > I can work around it temporarily for the
> > tests, but this will be a problem if any libpq clients load up multiple
> > independent databases for use with separate connections. Anyone know if
> > this is a supported use case for NSS?
> 
> Are you referring to the case of threading here?  This should be a
> supported case, as threads created by an application through libpq
> could perfectly use completely different connection strings.
Right, but to clarify -- I was asking if *NSS* supports loading and
using separate certificate databases as part of its API. It seems like
the internals make it possible, but I don't see the public interfaces
to actually use those internals.

--Jacob

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Custom compression methods
Next
From: John Naylor
Date:
Subject: Re: Tying an object's ownership to datdba