Re: Error-safe user functions

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.

cheers

andrew

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