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

From Andrew Dunstan
Subject Re: Error-safe user functions
Date
Msg-id d56179c3-86aa-dce1-7013-cb2473f0ace4@dunslane.net
Whole thread Raw
In response to Re: Error-safe user functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Error-safe user functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2022-12-25 Su 12:13, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Dec 16, 2022 at 1:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> The reg* functions probably need a unified plan as to how far
>>> down we want to push non-error behavior.
>> I would be in favor of an aggressive approach.
> Here's a proposed patch for converting regprocin and friends
> to soft error reporting.  I'll say at the outset that it's an
> engineering compromise, and it may be worth going further in
> future.  But I doubt it's worth doing more than this for v16,
> because the next steps would be pretty invasive.


It's a judgement call, but I'm not too fussed about stopping here for
v16. I see the reg* items as probably the lowest priority to fix.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Perform streaming logical transactions by background workers and parallel apply
Next
From: Dilip Kumar
Date:
Subject: Re: Perform streaming logical transactions by background workers and parallel apply