Re: Error-safe user functions

On 2022-12-07 We 09:20, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.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.