Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.2\))
Subject: Re: unclear OAuth error message
From: Daniel Gustafsson <daniel@yesql.se>
In-Reply-To: 
 <CAOYmi+mxcvtJ9QJhxd4SbYHk=+L9r3VrK0xJ1DsM+H3pFFUtGg@mail.gmail.com>
Date: Fri, 27 Mar 2026 23:24:40 +0100
Cc: Zsolt Parragi <zsolt.parragi@percona.com>,
 =?utf-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>,
 Pg Hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E187E05E-33C2-46E1-A324-160374CE1914@yesql.se>
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>
 <CAOYmi+mxcvtJ9QJhxd4SbYHk=+L9r3VrK0xJ1DsM+H3pFFUtGg@mail.gmail.com>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Archived-At: 
 <https://www.postgresql.org/message-id/E187E05E-33C2-46E1-A324-160374CE1914%40yesql.se>
Precedence: bulk

> On 27 Mar 2026, at 18:01, Jacob Champion =
<jacob.champion@enterprisedb.com> wrote:
>=20
> On Mon, Mar 23, 2026 at 2:21=E2=80=AFPM Zsolt Parragi =
<zsolt.parragi@percona.com> wrote:
>> Isn't including the detail for both the warning and the fatal error
>> still overly verbose?
>=20
> 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.
>=20
> (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.)

Agreed.

>> Shouldn't the oauth code include a sanity check to ensure validators
>> return no error_detail on success instead of silently ignoring it?
>=20
> 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.

Callsites can also clear the error message on success and not even rely =
on it
being ignored.

+	 * This string may be either of static duration or palloc'd.
+	 */
+	char	   *error_detail;

I'm not a big fan of "either static or allocated" and prefer if we just =
require
one or the other.  We have this pattern in other places so it's not a =
blocker
for going it, but.

--
Daniel Gustafsson