| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Joe Conway <mail(at)joeconway(dot)com>, Robert Haas <robertmhaas(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-07 14:20:33 |
| Message-ID: | 4009543.1670422833@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Muhammad Usama | 2022-12-07 14:48:01 | Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row |
| Previous Message | Peter Eisentraut | 2022-12-07 14:14:09 | Re: Allow tests to pass in OpenSSL FIPS mode |