On 2015-08-20 02:29, Tom Lane wrote:
Marko Tiikkaja <ma...@joh.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.
.m
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
