On Thu, Dec 1, 2022 at 1:14 PM Tom Lane <t...@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