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.)
> 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. I will not accept a solution that requires more than
the absolute minimum of additions to the error-reporting spots.
regards, tom lane