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

On 2022-12-03 Sa 16:46, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Great. Let's hope we can get this settled early next week and then we
>> can get to work on the next tranche of functions, those that will let
>> the SQL/JSON work restart.
> OK, here's a draft proposal.  I should start out by acknowledging that
> this steals a great deal from Nikita's original patch as well as yours,
> though I editorialized heavily.
>
> 0001 is the core infrastructure and documentation for the feature.
> (I didn't bother breaking it down further than that.)
>
> 0002 fixes boolin and int4in.  That is the work that we're going to
> have to replicate in an awful lot of places, and I am pleased by how
> short-and-sweet it is.  Of course, stuff like the datetime functions
> might be more complex to adapt.
>
> Then 0003 is a quick-hack version of COPY that is able to exercise
> all this.  I did not bother with the per-column flags as you had
> them, because I'm not sure if they're worth the trouble compared
> to a simple boolean; in any case we can add that refinement later.
> What I did add was a WARN_ON_ERROR option that exercises the ability
> to extract the error message after a soft error.  I'm not proposing
> that as a shippable feature, it's just something for testing.


Overall I think this is pretty good, and I hope we can settle on it quickly.


>
> 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.


I haven't got anything better than ereturn.

details_please seems more informal than our usual style. details_wanted
maybe?


>
> 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 ?
>
>             


Maybe a new header misc_nodes.h?

Soon after we get this done I think we'll find we need to extend this to
non-input functions. But that can wait a short while.



cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com