| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Joe Conway <mail(at)joeconway(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Error-safe user functions |
| Date: | 2022-12-06 01:19:26 |
| Message-ID: | 3524499.1670289566@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2022-12-06 01:49:20 | Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) |
| Previous Message | Andres Freund | 2022-12-06 01:14:04 | Re: Error-safe user functions |