Re: Error-safe user functions

Hi,

On 2022-12-05 20:06:55 -0500, Tom Lane wrote:
> >> I wasn't trying all that hard on the error tests, because I think
> >> 0003 is just throwaway code at this point.
>
> > I am mainly interested in having *something* test erroring out hard when
> > using the "Safe" mechanism, which afaict we don't have with the patches
> > as they stand. You're right that it'd be better to do that without COPY
> > in the way, but it doesn't seem all that crucial.
>
> Hmm, either I'm confused or you're stating that backwards --- aren't
> the hard-error code paths already tested by our existing tests?

What I'd like to test is a hard error, either due to an input function
that wasn't converted or because it's a type of error that can't be
handled "softly", but when using the "safe" interface.

> > But perhaps it's even worth having such a function properly exposed:
> > It's not at all rare to parse text data during ETL and quite often
> > erroring out fatally is undesirable. As savepoints are undesirable
> > overhead-wise, there's a lot of SQL out there that tries to do a
> > pre-check about whether some text could be cast to some other data
> > type. A function that'd try to cast input to a certain type without
> > erroring out hard would be quite useful for that.
>
> Corey and Vik are already talking about a non-error CAST variant.
> Maybe we should leave this in abeyance until something shows up
> for that? Otherwise we'll be making a nonstandard API for what
> will probably ultimately be SQL-spec functionality. I don't mind
> that as regression-test infrastructure, but I'm a bit less excited
> about exposing it as a user feature.

Yea, I'm fine with that. I was just thinking out loud on this aspect.

Greetings,

Andres Freund