Magnus Hagander 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.
Revisiting the whole issue seems like not material for back-patching.
Also the xreflabel for the variable in the docs isn't consistent,
You mean add _limit to it, right?
Right.
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.

regards, tom lane

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2022 Grokbase