On Fri, Mar 27, 2026 at 3:24 PM Daniel Gustafsson <[email protected]> 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
