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