On Thu, Dec 1, 2022 at 2:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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
