| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: unclear OAuth error message |
| Date: | 2026-03-27 23:20:53 |
| Message-ID: | CAOYmi+kGkXu5Ep_6yM6J1fgjfxpFVQ1aL44Au2OfU=fU+1vzrA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 27, 2026 at 3:24 PM Daniel Gustafsson <daniel(at)yesql(dot)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 on it
> being ignored.
Agreed, but are you saying that as an argument for my approach, or for Zsolt'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 require
> one or the other. We have this pattern in other places so it's not a blocker
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2026-03-27 23:30:56 | Re: Changing the state of data checksums in a running cluster |
| Previous Message | Sami Imseih | 2026-03-27 23:17:38 | Re: another autovacuum scheduling thread |