Re: Error-safe user functions

On Wed, Dec 7, 2022 at 8:04 AM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
> On 2022-12-07 We 09:20, Tom Lane wrote:
> > Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> >> Perhaps we should add a type in the regress library that will never have
> >> a safe input function, so we can test that the mechanism works as
> >> expected in that case even after we adjust all the core data types'
> >> input functions.
> > I was intending that the existing "widget" type be that. 0003 already
> > adds a comment to widget_in saying not to "fix" its one ereport call.
>
>
> Yeah, I see that, I must have been insufficiently caffeinated.
>
>
> >
> > Returning to the naming quagmire -- it occurred to me just now that
> > it might be helpful to call this style of error reporting "soft"
> > errors rather than "safe" errors, which'd provide a nice contrast
> > with "hard" errors thrown by longjmp'ing. That would lead to naming
> > all the variant functions XXXSoft not XXXSafe. There would still
> > be commentary to the effect that "soft errors must be safe, in the
> > sense that there's no question whether it's safe to continue
> > processing the transaction". Anybody think that'd be an
> > improvement?
> >
> >
>
>
> I'm not sure InputFunctionCallSoft would be an improvement. Maybe
> InputFunctionCallSoftError would be clearer, but I don't know that it's
> much of an improvement either. The same goes for the other visible changes.
>
>
InputFunctionCallSafe -> TryInputFunctionCall

I think in create type saying "input functions to handle errors softly" is
an improvement over "input functions to return safe errors".

start->save->finish describes a soft error handling procedure quite well.
safe has baggage, all code should be "safe".

fmgr/README: "Handling Non-Exception Errors" -> "Soft Error Handling"

"typical safe error conditions include" -> "error conditions that can be
handled softly include"

(pg_input_is_valid) "input function has been updated to return "safe'
errors" -> "input function has been updated to soft error handling"

Unrelated observation: "Although the error stack is not large, we don't
expect to run out of space." -> "Because the error stack is not large,
assume that we will not run out of space and panic if we are wrong."?

David J.