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>
 <CAOYmi+mxcvtJ9QJhxd4SbYHk=+L9r3VrK0xJ1DsM+H3pFFUtGg@mail.gmail.com>
 <E187E05E-33C2-46E1-A324-160374CE1914@yesql.se>
In-Reply-To: <E187E05E-33C2-46E1-A324-160374CE1914@yesql.se>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Fri, 27 Mar 2026 16:20:53 -0700
Message-ID: 
 <CAOYmi+kGkXu5Ep_6yM6J1fgjfxpFVQ1aL44Au2OfU=fU+1vzrA@mail.gmail.com>
Subject: Re: unclear OAuth error message
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Zsolt Parragi <zsolt.parragi@percona.com>,
 =?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%2BkGkXu5Ep_6yM6J1fgjfxpFVQ1aL44Au2OfU%3DfU%2B1vzrA%40mail.gmail.com>
Precedence: bulk

On Fri, Mar 27, 2026 at 3:24=E2=80=AFPM Daniel Gustafsson <daniel@yesql.se>=
 wrote:
> > 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 o=
n it
> being ignored.

Agreed, but are you saying that as an argument for my approach, or for Zsol=
t's?

> +        * 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 r=
equire
> one or the other.  We have this pattern in other places so it's not a blo=
cker
> for going it, but.

I don't think I can enforce either choice, though: I pass the
error_detail into the ereport(FATAL), so the process is about to go
down, and I'm never going to pfree() it.

--Jacob