On Fri, Oct 29, 2010 at 19:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Fri, Oct 29, 2010 at 10:01, Josh Berkus <josh@agliodbs.com> wrote:
>>> Mind you, we *also* need a doc patch. ("This parameter is only available if
>>> PostgreSQL was built with SSL support").
>
>> Actually, I think it'd be more user friendly to make the parameter
>> still exist and be a no-op (maybe show the value NULL?) on non-SSL
>> enabled builds. Same goes for all other parameters that depend on a
>> specific compile flag. That would make life easier on automated tools
>> *and* on people sitting down at a new installation.
>
> Yeah, we're a bit schizophrenic about this. Some parameters still
> exist, but can't be set to any value but "disabled", when the relevant
> feature wasn't compiled. Others just aren't there.
>
> It takes code space and work to make a parameter be present but behave
> differently if disabled. I don't think that we should institute a
> blanket policy of requiring that to happen; in particular, there are a
> number of debug-type parameters for which I argue that it's not worth
> the trouble. But for user-facing parameters I agree we should do it,
> and ssl_ciphers is one of those.
Here's a patch that does this for HEAD. AFAICT, only ssl_ciphers and
the syslog parameters are actually "user facing parameters" - all the
other ifdef'ed out ones are debug-style parameters.
> In any case, a doc patch would be the right thing for the back branches.
I can look at this too (yes, I know we just wrapped, but I'm working
down the backlog :S). You mean something as simple as "this parameter
is unavailable if the server was not compiled with support for SSL"?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
