From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-02 13:27:58 |
Message-ID: | CA+TgmoZ5tQz4sZfXOAK-wx7e2d2+pGg4EEc1TA4sb9gNMjm4Fw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 1, 2022 at 5:33 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
<sputters>
But you yourself proposed a new node called IOCallContext. It can't be
right to have the names be specific to I/O functions in one part of
the patch and totally generic in another part.
Hmm, but yesterday I see that you were now calling it FuncCallContext.
I think the design is evolving in your head as you think about this
more, which is totally understandable and actually very good. However,
this is also why I think that you should produce the patch you
actually want instead of letting other people repeatedly submit
patches and then complain that they weren't what you had in mind.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2022-12-02 13:29:42 | Re: Optimize common expressions in projection evaluation |
Previous Message | Richard Guo | 2022-12-02 13:16:07 | Re: Missing MaterialPath support in reparameterize_path_by_child |