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>, 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-01 22:33:45 |
Message-ID: | 1721519.1669934025@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:
> It sounds to me like we're crafting something that is specific to and
> can only be used with type input and output functions, so the name
> probably should reflect that rather than being something totally
> generic like ereturn() or error_stash() or whatever.
My opinion is exactly the opposite. Don't we already have a need
for error-safe type conversions, too, in the JSON stuff? Even if
I couldn't point to a need-it-now requirement, I think we will
eventually find a use for this with some other classes of functions.
> If we were making
> this into a general-purpose way of sticking an error someplace, then a
> name like that would make sense and this would be an extension of the
> elog.c interface. But what you're proposing is a great deal more
> specialized than that.
I'm proposing *exactly* an extension of the elog.c interface;
so were you, a couple messages back. It's only specialized to I/O
in the sense that our current need is for that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2022-12-01 23:35:13 | Re: Asynchronous execution support for Custom Scan |
Previous Message | David G. Johnston | 2022-12-01 21:51:58 | Re: Questions regarding distinct operation implementation |