From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: 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: <a6e7ac7e-30ec-5c9d-5134-16072aefc0d7@dunslane.net>
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>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Wed, 07 Dec 2022 08:47:37 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4009542.1670422833.1@sss.pgh.pa.us>
Date: Wed, 07 Dec 2022 09:20:33 -0500
Message-ID: <4009543.1670422833@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4009543.1670422833%40sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew@dunslane.net> writes:
> Perhaps we should add a type in the regress library that will never have
> a safe input function, so we can test that the mechanism works as
> expected in that case even after we adjust all the core data types'
> input functions.

I was intending that the existing "widget" type be that.  0003 already
adds a comment to widget_in saying not to "fix" its one ereport call.

Returning to the naming quagmire -- it occurred to me just now that
it might be helpful to call this style of error reporting "soft"
errors rather than "safe" errors, which'd provide a nice contrast
with "hard" errors thrown by longjmp'ing.  That would lead to naming
all the variant functions XXXSoft not XXXSafe.  There would still
be commentary to the effect that "soft errors must be safe, in the
sense that there's no question whether it's safe to continue
processing the transaction".  Anybody think that'd be an
improvement?

			regards, tom lane