Re: Error-safe user functions

>
> I think there are just a couple of loose ends here:
>
> 1. Bikeshedding on my name choices is welcome. I know Robert is
> dissatisfied with "ereturn", but I'm content with that so I didn't
> change it here.
>

1. details_please => include_error_data

as this hints the reader directly to the struct to be filled out

2. ereturn_* => errfeedback / error_feedback / efeedback

It is returned, but it's not taking control and the caller could ignore it.
I arrived at his after checking https://www.thesaurus.com/browse/report and
https://www.thesaurus.com/browse/hint.

> 2. Everybody has struggled with just where to put the declaration
> of the error context structure. The most natural home for it
> probably would be elog.h, but that's out because it cannot depend
> on nodes.h, and the struct has to be a Node type to conform to
> the fmgr safety guidelines. What I've done here is to drop it
> in nodes.h, as we've done with a couple of other hard-to-classify
> node types; but I can't say I'm satisfied with that.
>
> Other plausible answers seem to be:
>
> * Drop it in fmgr.h. The only real problem is that historically
> we've not wanted fmgr.h to depend on nodes.h either. But I'm not
> sure how strong the argument for that really is/was. If we did
> do it like that we could clean up a few kluges, both in this patch
> and pre-existing (fmNodePtr at least could go away).
>
> * Invent a whole new header just for this struct. But then we're
> back to the question of what to call it. Maybe something along the
> lines of utils/elog_extras.h ?
>

Would moving ErrorReturnContext and the ErrorData struct to their own
util/errordata.h allow us to avoid the void pointer for ercontext? If so,
that'd be a win because typed pointers give the reader some idea of what is
expected there, as well as aiding doxygen-like tools.

Overall this looks like a good foundation.

My own effort was getting bogged down in the number of changes I needed to
make in code paths that would never want a failover case for their
typecasts, so I'm going to refactor my work on top of this and see where I
get stuck.