Re: Remove last traces of SCM credential auth from libpq?
От
Tom Lane
Тема
Re: Remove last traces of SCM credential auth from libpq?
Дата
Msg-id
4037249.1679011812@sss.pgh.pa.us
Ответ на
Re: Remove last traces of SCM credential auth from libpq? (Michael Paquier)
Список
Дерево обсуждения
Remove last traces of SCM credential auth from libpq? Michael Paquier <michael@paquier.xyz>
Re: Remove last traces of SCM credential auth from libpq? Tom Lane <tgl@sss.pgh.pa.us>
Re: Remove last traces of SCM credential auth from libpq? "Jonathan S. Katz" <jkatz@postgresql.org>
Re: Remove last traces of SCM credential auth from libpq? Tom Lane <tgl@sss.pgh.pa.us>
Re: Remove last traces of SCM credential auth from libpq? Michael Paquier <michael@paquier.xyz>
Re: Remove last traces of SCM credential auth from libpq? Tom Lane <tgl@sss.pgh.pa.us>
Re: Remove last traces of SCM credential auth from libpq? Michael Paquier <michael@paquier.xyz>
Re: Remove last traces of SCM credential auth from libpq? Michael Paquier <michael@paquier.xyz>
Michael Paquier writes: > On Thu, Mar 16, 2023 at 10:49:45AM -0400, Tom Lane wrote: >> Also, in pg_fe_sendauth, couldn't you just let the default: case >> handle it instead of adding a bespoke error message? We're not >> really expecting that anyone is ever going to hit this, so I'm >> not convinced it's worth the translation burden. > Yes, I was wondering if that's worth keeping or not, so I chose > consistency with AUTH_REQ_KRB4 and AUTH_REQ_KRB5. Maybe flush those special messages too? I'm not sure how long they've been obsolete, though. > Would it be better to hold on this patch for 17~? Nah, I see no reason to wait. We already dropped the higher-level client support (psql/pg_dump) for these server versions in v15. regards, tom lane
В списке pgsql-hackers по дате отправления
От: Amit Kapila
Дата:
От: Tom Lane
Дата: