Re: Supporting fallback RADIUS server(s)

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:
>
>> Marko Tiikkaja <marko(at)joh(dot)to> writes:
>>
>>> So I'm developing a patch to fix this issue, but I'm not
>>> exactly sure what the configuration should look like. I see multiple
>>> options, but the one I like the best is the following:
>>>
>>
>> Add two new HBA configuration options: radiusfallbackservers and
>>> radiusfallbackports; both lists parsed with SplitIdentifierString (Ã la
>>> listen_addresses).
>>>
>>
>> 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?
>>
>> Or maybe better, rename it radius_servers. But what you have here seems
>> weird, and it certainly doesn't follow the precedent of what we did when
>> we replaced listen_address with listen_addresses.
>>
>
> If we were adding RADIUS support today, this would be the best option. But
> seeing that we still only support one server today, this seems like a
> backwards incompatibility which practically 100% of users won't benefit
> from. But I don't care much either way. If we think breaking
> compatibility here is acceptable, I'd say we go for radius_servers and
> radius_ports.

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.

And we could consider throwing a WARNING or at least a LOG when the old
name is used, indicating that it's deprecated.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/