Re: Supporting fallback RADIUS server(s)

On Aug 20, 2015 4:16 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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.
>

Well, that's true of any depreciation. And if we throw a log message then
people will know about it...

That said, I'm not against a clean break with compatibility either. As long
as it's clean - like renaming the parameters.

/Magnus