Re: Error-safe user functions
| От | Corey Huinker |
|---|---|
| Тема | Re: Error-safe user functions |
| Дата | |
| Msg-id | CADkLM=end5RBrsQMfyB8VxvOmu5AZzsffQbDJge3TjtkxUGkEQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Error-safe user functions (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Error-safe user functions
Re: Error-safe user functions |
| Список | 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.
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 по дате отправления: