pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David G. Johnston <david.g.johnston@gmail.com>
Cc: 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 15:16:16 -0500
Message-ID: <4111458.1670444176@sss.pgh.pa.us> (raw)
In-Reply-To: <CAKFQuwYdQqQru9tpMpY4JpCEJ8OeN8kwmBG6DY2QyzE+5znA6Q@mail.gmail.com>
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>
	<CAKFQuwYdQqQru9tpMpY4JpCEJ8OeN8kwmBG6DY2QyzE+5znA6Q@mail.gmail.com>

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Wed, Dec 7, 2022 at 8:04 AM Andrew Dunstan <andrew@dunslane.net> wrote:
>> 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.

> InputFunctionCallSafe -> TryInputFunctionCall

I think we are already using "TryXXX" for code that involves catching
ereport errors.  Since the whole point here is that we are NOT doing
that, I think this naming would be more confusing than helpful.

> Unrelated observation: "Although the error stack is not large, we don't
> expect to run out of space." -> "Because the error stack is not large,
> assume that we will not run out of space and panic if we are wrong."?

That doesn't seem to make the point I wanted to make.

I've adopted your other suggestions in the v4 I'm preparing now.

			regards, tom lane





view thread (175+ messages)  latest in thread

Message-ID: <4111458.1670444176@sss.pgh.pa.us>
Permalink:  ../4111458.1670444176@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/4111458.1670444176@sss.pgh.pa.us

 · 

reply
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, david.g.johnston@gmail.com, 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: <4111458.1670444176@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