public inbox for [email protected]  

help / color / mirror / Atom feed

From: Daniel Gustafsson <[email protected]>
To: Jacob Champion <[email protected]>
Cc: Zsolt Parragi <[email protected]>
Cc: Álvaro Herrera <[email protected]>
Cc: Pg Hackers <[email protected]>
Subject: Re: unclear OAuth error message
Date: Fri, 27 Mar 2026 23:24:40 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAOYmi+mxcvtJ9QJhxd4SbYHk=+L9r3VrK0xJ1DsM+H3pFFUtGg@mail.gmail.com>
References: <[email protected]>
	<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>

> On 27 Mar 2026, at 18:01, Jacob Champion <[email protected]> wrote:
> 
> On Mon, Mar 23, 2026 at 2:21 PM Zsolt Parragi <[email protected]> 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.)

Agreed.

>> 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.

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

view thread (12+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: unclear OAuth error message
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox