From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
cc: Andrew Dunstan <andrew@dunslane.net>,
        Corey Huinker <corey.huinker@gmail.com>,
        Andres Freund <andres@anarazel.de>,
        Alvaro Herrera <alvherre@alvh.no-ip.org>,
        Joe Conway <mail@joeconway.com>, Robert Haas <robertmhaas@gmail.com>,
        Nikita Glukhov <n.gluhov@postgrespro.ru>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Error-safe user functions
In-reply-to: 
 <CAKFQuwYdQqQru9tpMpY4JpCEJ8OeN8kwmBG6DY2QyzE+5znA6Q@mail.gmail.com>
References: <20221205174231.6wpmbuxafnfzlbuh@alvherre.pgsql>
 <85e40849-4458-bbb9-62ee-d9e7faf0c7dc@dunslane.net>
 <3323802.1670263204@sss.pgh.pa.us> <3496391.1670276406@sss.pgh.pa.us>
 <20221205234734.sab3fuxy6q2sokjd@alap3.anarazel.de>
 <3518534.1670285891@sss.pgh.pa.us>
 <20221206005607.lxcrazckoalptwds@alap3.anarazel.de>
 <3523582.1670288815@sss.pgh.pa.us>
 <40ff1ed1-4245-e343-bffa-c7755b031492@dunslane.net>
 <CADkLM=coVJ0Hy-yYtXbN_dhfc453zs_BUTTPHmJqv12Urkd79g@mail.gmail.com>
 <3889877.1670358069@sss.pgh.pa.us>
 <a6e7ac7e-30ec-5c9d-5134-16072aefc0d7@dunslane.net>
 <4009543.1670422833@sss.pgh.pa.us>
 <6acddf68-7cb7-e9e7-a5a7-0abc87b3c55b@dunslane.net>
 <CAKFQuwYdQqQru9tpMpY4JpCEJ8OeN8kwmBG6DY2QyzE+5znA6Q@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Wed, 07 Dec 2022 08:33:11 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4111457.1670444176.1@sss.pgh.pa.us>
Date: Wed, 07 Dec 2022 15:16:16 -0500
Message-ID: <4111458.1670444176@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4111458.1670444176%40sss.pgh.pa.us>
Precedence: bulk

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Wed, Dec 7, 2022 at 8:04 AM Andrew Dunstan <andrew@dunslane.net> wrote:
>> I'm not sure InputFunctionCallSoft would be an improvement. Maybe
>> InputFunctionCallSoftError would be clearer, but I don't know that it's
>> much of an improvement either. The same goes for the other visible changes.

> InputFunctionCallSafe -> TryInputFunctionCall

I think we are already using "TryXXX" for code that involves catching
ereport errors.  Since the whole point here is that we are NOT doing
that, I think this naming would be more confusing than helpful.

> Unrelated observation: "Although the error stack is not large, we don't
> expect to run out of space." -> "Because the error stack is not large,
> assume that we will not run out of space and panic if we are wrong."?

That doesn't seem to make the point I wanted to make.

I've adopted your other suggestions in the v4 I'm preparing now.

			regards, tom lane