Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p2vy1-0007LH-7J for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Dec 2022 15:04:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p2vxz-0004Mv-MA for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Dec 2022 15:04:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p2vxz-0004LX-CM for pgsql-hackers@lists.postgresql.org; Wed, 07 Dec 2022 15:04:11 +0000 Received: from relay4-d.mail.gandi.net ([2001:4b98:dc4:8::224]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p2vxw-0006G6-KR for pgsql-hackers@lists.postgresql.org; Wed, 07 Dec 2022 15:04:10 +0000 Received: (Authenticated sender: adsend@dunslane.net) by mail.gandi.net (Postfix) with ESMTPSA id C86ABE000B; Wed, 7 Dec 2022 15:04:02 +0000 (UTC) Message-ID: <6acddf68-7cb7-e9e7-a5a7-0abc87b3c55b@dunslane.net> Date: Wed, 7 Dec 2022 10:04:01 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Error-safe user functions Content-Language: en-US To: Tom Lane Cc: Corey Huinker , Andres Freund , Alvaro Herrera , Joe Conway , Robert Haas , Nikita Glukhov , PostgreSQL Hackers 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> <3889877.1670358069@sss.pgh.pa.us> <4009543.1670422833@sss.pgh.pa.us> From: Andrew Dunstan In-Reply-To: <4009543.1670422833@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-12-07 We 09:20, Tom Lane wrote: > Andrew Dunstan 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