Re: Supporting fallback RADIUS server(s) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Supporting fallback RADIUS server(s)
Date
Msg-id 17866.1440080172@sss.pgh.pa.us
Whole thread Raw
In response to Re: Supporting fallback RADIUS server(s)  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Supporting fallback RADIUS server(s)  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> On Thu, Aug 20, 2015 at 2:36 AM, Marko Tiikkaja <marko@joh.to> wrote:
>> On 2015-08-20 02:29, Tom Lane wrote:
>>> Why add new GUCs for that?  Can't we just redefine radiusserver as a list
>>> of servers to try in sequence, and similarly split radiusport into a list?

> We could change it to radius_servers and radius_ports, and deprecate but
> keep accepting the old parameters for a release or two. To make it easy, we
> make sure that both parameter names accepts the same format parameter, so
> it's easy enough to just replace it once deprecated.

Considering that we did no such thing for listen_address, which is of
concern to probably two or three orders-of-magnitude more users than
radiusserver, I don't really see why we'd do it for the RADIUS settings.

Our expectations about forward compatibility for postgresql.conf entries
have always been pretty low; even more so for not-widely-used settings.

In any case, wouldn't what you describe simply put off the pain for awhile
(replacing it with confusion in the short term)?  Eventually we're going
to break it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: exposing pg_controldata and pg_config as functions
Next
From: Tom Lane
Date:
Subject: Re: Extension upgrade and GUCs