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

From Tom Lane
Subject Re: Error-safe user functions
Date
Msg-id 1721519.1669934025@sss.pgh.pa.us
Whole thread Raw
In response to Re: Error-safe user functions  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Error-safe user functions  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 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.

My opinion is exactly the opposite.  Don't we already have a need
for error-safe type conversions, too, in the JSON stuff?  Even if
I couldn't point to a need-it-now requirement, I think we will
eventually find a use for this with some other classes of functions.

> 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.

I'm proposing *exactly* an extension of the elog.c interface;
so were you, a couple messages back.  It's only specialized to I/O
in the sense that our current need is for that.

            regards, tom lane



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Questions regarding distinct operation implementation
Next
From: Kohei KaiGai
Date:
Subject: Re: Asynchronous execution support for Custom Scan