On Wed, Feb 24, 2010 at 17:47, Tom Lane wrote:
Magnus Hagander <magnus@hagander.net> writes:
2010/2/24 Tom Lane <tgl@sss.pgh.pa.us>:
Also, the coding seems a bit confused about whether the
ssl_renegotiation_limit GUC exists when USE_SSL isn't set.  I think we
have a project policy about whether GUCs should still exist when the
underlying support isn't compiled, but I forget what it is :-(.
I personally find it highly annoying when a GUC goes away, so I'm all
for always having them there. And I thought that was our policy for
new ones, but I can't find a reference to it...
I see that ssl_ciphers is made to go away when USE_SSL isn't set,
so the most consistent thing in the near term would be to do the same.
The difference is that ssl_ciphers is only set in postgresql.conf, so
it doesn't have the same exposure. I can certainly see a use-case
where a naive application will just disable ssl renegotiation because
it knows it can't deal with it (or the driver can't) uncondinionally -
but the use of SSL or not is controlled by the server at the other end
of the connection. Not failing then would be good..
Revisiting the whole issue seems like not material for back-patching.
Is this something we should consider looking over for 9.0,or is it too
late already? (For other parameters, that is - a check of all the ones
we have that are #ifdef:ed out today, to see if they can be made
available even when the support isn't compiled in)
SUSET seems less surprising to me.  I agree that it's hard to make
a concrete case for a user doing anything terribly bad with it,
but on the other hand is there much value in letting it be USERSET?
The use case would be for example npgsql (or npgsql clients) being
able to disable it from the client side, because they know they can't
deal with it. Even in the case that the server doesn't know that.
Fair enough, USERSET it is then.
Done. Will run some tests and then apply.

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2022 Grokbase