Re: Error-safe user functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Error-safe user functions
Date
Msg-id 4111458.1670444176@sss.pgh.pa.us
Whole thread Raw
In response to Re: Error-safe user functions  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Error-safe user functions
List pgsql-hackers
"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



pgsql-hackers by date:

Previous
From: Christoph Heiss
Date:
Subject: [PATCH] psql: Add tab-complete for optional view parameters
Next
From: Fabrízio de Royes Mello
Date:
Subject: Re: [PATCH] pg_dump: lock tables in batches