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: <6acddf68-7cb7-e9e7-a5a7-0abc87b3c55b@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>
 <4009543.1670422833@sss.pgh.pa.us>
 <6acddf68-7cb7-e9e7-a5a7-0abc87b3c55b@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Wed, 07 Dec 2022 10:04:01 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4026788.1670426602.1@sss.pgh.pa.us>
Date: Wed, 07 Dec 2022 10:23:22 -0500
Message-ID: <4026789.1670426602@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4026789.1670426602%40sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew@dunslane.net> writes:
> On 2022-12-07 We 09:20, Tom Lane wrote:
>> 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.

> I'm not sure InputFunctionCallSoft would be an improvement.

Yeah, after reflecting on it a bit more I'm not that impressed with
that as a function name either.

(I think that "soft error" could be useful as informal terminology.
AFAIR we don't use "hard error" in any formal way either, but there
are certainly comments using that phrase.)

More questions:

* Anyone want to bikeshed about the new SQL-level function names?
I'm reasonably satisfied with "pg_input_is_valid" for the bool-returning
variant, but not so much with "pg_input_invalid_message" for the
error-message-returning variant.  Thinking about "pg_input_error_message"
instead, but that's not stellar either.

* Where in the world shall we document these, if we document them?
The only section of chapter 9 that seems even a little bit appropriate
is "9.26. System Information Functions and Operators", and even there,
they would need their own new table because they don't fit well in any
existing table.

BTW, does anyone else agree that 9.26 is desperately in need of some
<sect2> subdivisions?  It seems to have gotten a lot longer since
I looked at it last.

			regards, tom lane