On Thu, Dec 1, 2022 at 2:41 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: > > It sounds like you're imagining that ereturn doesn't return, which > > seems confusing. But I don't know that I'd like it better if it did. > > The spec I had in mind was that it would behave as ereport(ERROR) > unless a suitable FuncErrorContext node is passed, in which case > it'd store the error data into that node and return. This leaves > the invoker with only the job of passing control back afterwards, > if it gets control back. I'd be the first to agree that "ereturn" > doesn't capture that detail very well, but I don't have a better name. > (And I do like the fact that this name is the same length as "ereport", > so that we won't end up with lots of reindentation to do.)
I don't think it's sensible to make decisions about important syntax on the basis of byte-length. Reindenting is a one-time effort; code clarity will be with us forever. > > Magic return statements hidden inside macros seem not too fun. What > > I'd like to see is a macro that takes a pointer to an ErrorData and > > the rest of the arguments like ereport() and stuffs everything in > > there. And then you can pass that to ThrowErrorData() later if you > > like. That way it's visible when you're using the macro where you're > > putting the error. I think that would make the code more readable. > > I think that'd just complicate the places that are having to report > such errors --- of which there are likely to be hundreds by the time > we are done. OK, that's a fair point. -- Robert Haas EDB: http://www.enterprisedb.com