Re: Supporting fallback RADIUS server(s)

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Thu, Aug 20, 2015 at 2:36 AM, Marko Tiikkaja <marko(at)joh(dot)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