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

From Robert Haas
Subject Re: Error-safe user functions
Date
Msg-id CA+TgmoaxLcxpLmFJ=QiOThfPRGLhRH+o2XZmVie2KOk5TKGbKg@mail.gmail.com
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 Thu, Dec 1, 2022 at 3:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I don't think it's sensible to make decisions about important syntax
> > on the basis of byte-length. Reindenting is a one-time effort; code
> > clarity will be with us forever.
>
> Sure, but without a proposal for a better name, that's irrelevant.

Sure, but you're far too clever not to be able to come up with
something good without any help from me. io_error_return_or_throw()?
store_or_report_io_error()? Or just store_io_error()?

It sounds to me like we're crafting something that is specific to and
can only be used with type input and output functions, so the name
probably should reflect that rather than being something totally
generic like ereturn() or error_stash() or whatever. If we were making
this into a general-purpose way of sticking an error someplace, then a
name like that would make sense and this would be an extension of the
elog.c interface. But what you're proposing is a great deal more
specialized than that.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Using WaitEventSet in the postmaster
Next
From: David Rowley
Date:
Subject: Re: Allow round() function to accept float and double precision