From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Corey Huinker <corey.huinker@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Joe Conway <mail@joeconway.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Nikita Glukhov <n.gluhov@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Error-safe user functions
Date: Wed, 07 Dec 2022 10:23:22 -0500
Message-ID: <4026789.1670426602@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew@dunslane.net, corey.huinker@gmail.com, andres@anarazel.de, alvherre@alvh.no-ip.org, mail@joeconway.com, robertmhaas@gmail.com, n.gluhov@postgrespro.ru, pgsql-hackers@lists.postgresql.org
Subject: Re: Error-safe user functions
In-Reply-To: <4026789.1670426602@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox