Re: Support for NSS as a libpq TLS backend
| От | Jacob Champion |
|---|---|
| Тема | Re: Support for NSS as a libpq TLS backend |
| Дата | |
| Msg-id | 05da9d530ab01e6959bd50c993d590ad73575c21.camel@vmware.com обсуждение исходный текст |
| Ответ на | Re: Support for NSS as a libpq TLS backend (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: Support for NSS as a libpq TLS backend
|
| Список | 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 по дате отправления: