MIME-Version: 1.0
References: <202601241015.y5uvxd7oxnfs@alvherre.pgsql>
 <CAOYmi+kLmjJmtmkKs1mWcmNFsgQWsY8ajRhctsrmeVy-y6OKFw@mail.gmail.com>
 <CAOYmi+naxE5os6dSPpVp-=ip=xv_dfmtypOOjzEfreA2KgVPTA@mail.gmail.com>
 <CAOYmi+kCD3GmTZMQKC=zXZb10SpVX3FpztUZaqMwZ5BJr-G=tg@mail.gmail.com>
 <CAN4CZFOXdgVT-HQQvjQVushcQtiBovcrLz4ohLtkCKXBWgN_VA@mail.gmail.com>
In-Reply-To: 
 <CAN4CZFOXdgVT-HQQvjQVushcQtiBovcrLz4ohLtkCKXBWgN_VA@mail.gmail.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Fri, 27 Mar 2026 10:01:59 -0700
Message-ID: 
 <CAOYmi+mxcvtJ9QJhxd4SbYHk=+L9r3VrK0xJ1DsM+H3pFFUtGg@mail.gmail.com>
Subject: Re: unclear OAuth error message
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>,
	Pg Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2BmxcvtJ9QJhxd4SbYHk%3D%2BL9r3VrK0xJ1DsM%2BH3pFFUtGg%40mail.gmail.com>
Precedence: bulk

On Mon, Mar 23, 2026 at 2:21=E2=80=AFPM Zsolt Parragi <zsolt.parragi@percon=
a.com> wrote:
> Isn't including the detail for both the warning and the fatal error
> still overly verbose?

I'm not too worried about verbosity for an internal error situation;
users shouldn't see it. If they do, I don't mind being very loud about
whose fault it is.

(I'm also influenced by some recent support work on clusters that have
huge log volumes. If someone is focused on the internal error, they
should be able to see at a glance what caused that error, and if
someone is focused on the authentication failure, they should be able
to see at a glance what caused that. The more logs you have to
correlate in a "help! no one can log in" panic situation, the less
likely you are to succeed.)

> Shouldn't the oauth code include a sanity check to ensure validators
> return no error_detail on success instead of silently ignoring it?

IMO, no. I don't want error_detail to add semantics to the API, just
descriptive power. Plus, I think a design that sets a possible error
message before entering a complex operation, knowing that it will be
ignored on success, is perfectly valid. libpq-oauth, and to a lesser
extent libpq, make use of that pattern.

--Jacob