Re: Error-safe user functions

On Wed, Dec 7, 2022 at 9:20 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.
>
> 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?

In my attempt to implement CAST...DEFAULT, I noticed that I immediately
needed an
OidInputFunctionCallSafe, which was trivial but maybe something we want to
add to the infra patch, but the comments around that function also somewhat
indicate that we might want to just do the work in-place and call
InputFunctionCallSafe directly. Open to both ideas.

Looking forward cascades up into coerce_type and its brethren, and
reimplementing those from a Node returner to a boolean returner with a Node
parameter seems a bit of a stretch, so I have to pick a point where the
code pivots from passing down a safe-mode indicator and passing back a
found_error indicator (which may be combine-able, as safe is always true
when the found_error pointer is not null, and always false when it isn't),
but for the most part things look do-able.