On Mon, Aug 21, 2017 at 6:21 AM, Daniel Gustafsson <dan...@yesql.se> wrote: >> On 19 Aug 2017, at 23:13, Thomas Munro <thomas.mu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
