Re: Time to drop RADIUS support?
| От | Thomas Munro |
|---|---|
| Тема | Re: Time to drop RADIUS support? |
| Дата | |
| Msg-id | CA+hUKGKXHBCptORqu2jZf5o0Gw45Q7YMW9wKmrXYDm35uQStoA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Time to drop RADIUS support? (Jacob Champion <jacob.champion@enterprisedb.com>) |
| Ответы |
Re: Time to drop RADIUS support?
|
| Список | pgsql-hackers |
On Sat, Jan 24, 2026 at 6:50 AM Jacob Champion <jacob.champion@enterprisedb.com> wrote: > On Fri, Jan 23, 2026 at 8:30 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > I don't think removing it entirely from all back branches is a good > > > idea, without first making sure that there are no users. > > > > Agreed, we can't pull it from the back branches. But I'm in favor of > > pulling it from HEAD if we document how to use PAM-based RADIUS > > instead. I agree with Thomas' argument that the cost-benefit ratio > > of fixing our implementation would be poor. > > +1. Great, it sounds like we have a plan. I think the wiki might be a good place for that documentation. The details are likely to change, and I wouldn't want to have to maintain that information in-tree, so I created some PAM how-to documentation at https://wiki.postgresql.org/wiki/RADIUS after testing on Debian and FreeBSD. We could point to that from the 19 release notes and in the deprecation notice added to the documentation for 14-18, calling it "community-maintained guidance on migration to supported configurations". Do we need to keep any trace of this in the 19 docs, and if so, where? A new tombstone section?
В списке pgsql-hackers по дате отправления: