On Thu, Dec 1, 2022 at 1:14 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The main objection is that we shouldn't be passing back a "char *"
> error string (though I observe that your 0003 and 0004 patches aren't
> even bothering to do that much). I think we want to pass back a
> fully populated ErrorData struct so that we can report everything
> the actual error would have done (notably, the SQLSTATE).
+1.
> That means that elog.h/.c has to be intimately involved in this.
> I liked Nikita's
> overall idea of introducing an "ereturn" macro, with the idea that
> where we have, say,
>
> ereport(ERROR,
> (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
> errmsg("value \"%s\" is out of range for type %s",
> s, "integer")));
>
> we would write
>
> ereturn(context, ERROR,
> (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
> errmsg("value \"%s\" is out of range for type %s",
> s, "integer")));
> return NULL; // or whatever is appropriate
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.
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.
> Also, as I said before, the absolute first priority has to be
> documentation explaining what function authors are supposed to
> do differently than before.
+1.
> I'd be willing to have a go at this myself, except that Corey
> said he was working on it, so I don't want to step on his toes.
Time is short, and I do not think Corey will be too sad if you decide
to have a go at it. The chances of person A being able to write the
code person B is imagining as well as person B could write it are not
great, regardless of who A and B are. And I think the general
consensus around here is that you're a better coder than most.
--
Robert Haas
EDB: http://www.enterprisedb.com