| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Joe Conway <mail(at)joeconway(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 20:29:15 |
| Message-ID: | 3891064.1670358555@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I feel like this can go either way. If we pick a name that conveys a
> specific intended behavior now, and then later we want to pass some
> other sort of node for some purpose other than ignoring errors, it's
> unpleasant to have a name that sounds like it can only ignore errors.
> But if we never use it for anything other than ignoring errors, a
> specific name is clearer.
With Andres' proposal to make the function return boolean succeed/fail,
I think it's pretty clear that the only useful case is to pass an
ErrorSaveContext. There may well be future APIs that pass some other
kind of context object to input functions, but they'll presumably
have different goals and want a different sort of wrapper function.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2022-12-06 20:35:35 | Re: Cygwin cleanup |
| Previous Message | Tom Lane | 2022-12-06 20:21:09 | Re: Error-safe user functions |