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. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
