Re: Improve OAuth discovery logging

From: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Improve OAuth discovery logging
Date: 2026-03-16 19:45:07
Message-ID: CAN4CZFP--Ec8hMgpu7JojgK9qS08bNnev0c6goA++T4Ozy8bOQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I don't
> want to escape the authentication flow from inside a SASL mech, though
> (it's unusual/invisible to other maintainers, plus it bypasses the
> ClientAuthentication_hook).

I tried to figure out if this is fine or not, but isn't it the same as
the existing ereport(ERROR, ...) calls everywhere in the sasl/scram
code? I didn't see any clear pattern, for example the LDAP code
clearly uses

ereport(LOG, ...);
return STATUS_ERROR;

even for internal/configuration errors, while the scram/sasl code
uses ereport(ERROR, ...) for those errors.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2026-03-16 20:01:27 Re: Expanding HOT updates for expression and partial indexes
Previous Message Nathan Bossart 2026-03-16 19:34:34 Re: pg_restore --format= option(without any value) should report an error as pg_dump is reporting an error