Re: Error-safe user functions - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Error-safe user functions
Date
Msg-id CADkLM=end5RBrsQMfyB8VxvOmu5AZzsffQbDJge3TjtkxUGkEQ@mail.gmail.com
Whole thread Raw
In response to Re: Error-safe user functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Error-safe user functions
Re: Error-safe user functions
List pgsql-hackers
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.
 

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Improve performance of pg_strtointNN functions
Next
From: Tom Lane
Date:
Subject: Re: Error-safe user functions