On Wed, Feb 24, 2010 at 17:47, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: >> 2010/2/24 Tom Lane <t...@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. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers