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

From Robert Haas
Subject Re: Error-safe user functions
Date
Msg-id CA+TgmobMiUQAV-8+2T9JgcMD7VjXB=69eDE=xqdqAFfi4D0JHA@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 Mon, Dec 5, 2022 at 12:09 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> But it does return, or at least you need to code on the assumption
> that it will.  (The cases where it doesn't aren't much different
> from any situation where a called subroutine unexpectedly throws
> an error.  Callers typically don't have to consider that.)

Are you just trolling me here?

AIUI, the macro never returns in the sense of using the return
statement, unlike PG_RETURN_WHATEVER(), which do. It possibly
transfers control by throwing an error. But that is also true of just
about everything you do in PostgreSQL code, because errors can get
thrown from almost anywhere. So clearly the possibility of a non-local
transfer of control is not the issue here. The issue is the
possibility that there will be NO transfer of control. That is, you
are compelled to write ereturn() and then afterwards you still need a
return statement.

I do not understand how it is possible to sensibly argue that someone
won't see a macro called ereturn() and perhaps come to the false
conclusion that it will always return.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Allow placeholders in ALTER ROLE w/o superuser
Next
From: Tom Lane
Date:
Subject: Re: Error-safe user functions