On Wed, Dec 7, 2022 at 8:04 AM Andrew Dunstan <and...@dunslane.net> wrote:
> > On 2022-12-07 We 09:20, Tom Lane wrote: > > Andrew Dunstan <and...@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". 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.
