From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
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, 7 Dec 2022 10:04:01 -0500
Message-ID: <6acddf68-7cb7-e9e7-a5a7-0abc87b3c55b@dunslane.net> (raw)
In-Reply-To: <4009543.1670422833@sss.pgh.pa.us>
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>
On 2022-12-07 We 09:20, Tom Lane wrote:
> 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.
Yeah, I see that, I must have been insufficiently caffeinated.
>
> 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?
>
>
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.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
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: andrew@dunslane.net, tgl@sss.pgh.pa.us, 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: <6acddf68-7cb7-e9e7-a5a7-0abc87b3c55b@dunslane.net>
* 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