Re: [HACKERS] Support for Secure Transport SSL library on macOS asOpenSSL alternative
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] Support for Secure Transport SSL library on macOS asOpenSSL alternative |
Дата | |
Msg-id | CAB7nPqRxrt9J3afm_1nmo649+so37bqX3KjKjuaDpJe3CH76+A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Support for Secure Transport SSL library on macOS as OpenSSL alternative (Daniel Gustafsson <daniel@yesql.se>) |
Ответы |
Re: [HACKERS] Support for Secure Transport SSL library on macOS asOpenSSL alternative
|
Список | pgsql-hackers |
On Mon, Aug 21, 2017 at 6:21 AM, Daniel Gustafsson <daniel@yesql.se> wrote: >> On 19 Aug 2017, at 23:13, Thomas Munro <thomas.munro@enterprisedb.com> wrote: >>> I guess it should have a fallback definition, though I don't know what >>> it should be. >> >> Or maybe the guc should only exist if SSL_LIBRARY is defined? > > I think the intended use case of the GUC should drive the decision on fallback. > If the GUC isn’t supposed to be a way to figure out if the server was built > with SSL support, then not existing in non-SSL backends is fine. If, however, > we want to allow using the GUC to see if the server has SSL support, then there > needs to be a “None” or similar value for that case. Only GUCs related to debugging have their existence defined based on a #define, so it seems to me that if Postgres is compiled without any SSL support, this parameter should still be visible, but set to "none". -- Michael
В списке pgsql-hackers по дате отправления: