From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Andrew Dunstan <andrew@dunslane.net>,
        Corey Huinker <corey.huinker@gmail.com>,
        Nikita Glukhov <n.gluhov@postgrespro.ru>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Error-safe user functions
In-reply-to: 
 <CA+TgmoaxLcxpLmFJ=QiOThfPRGLhRH+o2XZmVie2KOk5TKGbKg@mail.gmail.com>
References: <3bbbb0df-7382-bf87-9737-340ba096e034@postgrespro.ru>
 <3190059.1665164276@sss.pgh.pa.us>
 <57b7cc2e-1215-3f43-84e4-6d9f8ad575df@dunslane.net>
 <CADkLM=djieyppZpKgveeDdt3QYLt+XQGHzpoa+Sd_Lwa5dDTWA@mail.gmail.com>
 <3049337.1669008405@sss.pgh.pa.us>
 <469338a3-da38-160f-23b9-813c261bc1d6@dunslane.net>
 <1677334.1669918475@sss.pgh.pa.us>
 <CA+TgmoY44nbY6Z7zbnQ1VwgDu79DbOHmh4o8K9cBu0OeC2Hndw@mail.gmail.com>
 <1695760.1669923671@sss.pgh.pa.us>
 <CA+TgmobpfOx0WT+ZG71eB5=JrKUi-VX7FwsVF6E8ps1WfKYYcQ@mail.gmail.com>
 <1703871.1669927782@sss.pgh.pa.us>
 <CA+TgmoaxLcxpLmFJ=QiOThfPRGLhRH+o2XZmVie2KOk5TKGbKg@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Thu, 01 Dec 2022 16:15:17 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1721518.1669934025.1@sss.pgh.pa.us>
Date: Thu, 01 Dec 2022 17:33:45 -0500
Message-ID: <1721519.1669934025@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1721519.1669934025%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.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