Re: Error-safe user functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Error-safe user functions
Date
Msg-id 3524499.1670289566@sss.pgh.pa.us
Whole thread Raw
In response to Re: Error-safe user functions  (Andres Freund <andres@anarazel.de>)
Responses Re: Error-safe user functions  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2022-12-05 20:06:55 -0500, Tom Lane wrote:
>> 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.

Oh, I see.  That seems like kind of a problematic requirement,
unless we leave some datatype around that's intentionally not
ever going to be converted.  For datatypes that we do convert,
there shouldn't be any easy way to get to a hard error.

I don't really quite understand why you're worried about that
though.  The hard-error code paths are well tested already.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Error-safe user functions
Next
From: Melanie Plageman
Date:
Subject: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)