From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Corey Huinker <corey.huinker@gmail.com>
Cc: Nikita Glukhov <n.gluhov@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Error-safe user functions
Date: Thu, 01 Dec 2022 14:41:11 -0500
Message-ID: <1695760.1669923671@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+TgmoY44nbY6Z7zbnQ1VwgDu79DbOHmh4o8K9cBu0OeC2Hndw@mail.gmail.com>
References: <3bbbb0df-7382-bf87-9737-340ba096e034@postgrespro.ru>
<3190059.1665164276@sss.pgh.pa.us>
<57b7cc2e-1215-3f43-84e4-6d9f8ad575df@dunslane.net>
<CADkLM=djieyppZpKgveeDdt3QYLt+XQGHzpoa+Sd_Lwa5dDTWA@mail.gmail.com>
<3049337.1669008405@sss.pgh.pa.us>
<469338a3-da38-160f-23b9-813c261bc1d6@dunslane.net>
<1677334.1669918475@sss.pgh.pa.us>
<CA+TgmoY44nbY6Z7zbnQ1VwgDu79DbOHmh4o8K9cBu0OeC2Hndw@mail.gmail.com>
Robert Haas <robertmhaas@gmail.com> writes:
> It sounds like you're imagining that ereturn doesn't return, which
> seems confusing. But I don't know that I'd like it better if it did.
The spec I had in mind was that it would behave as ereport(ERROR)
unless a suitable FuncErrorContext node is passed, in which case
it'd store the error data into that node and return. This leaves
the invoker with only the job of passing control back afterwards,
if it gets control back. I'd be the first to agree that "ereturn"
doesn't capture that detail very well, but I don't have a better name.
(And I do like the fact that this name is the same length as "ereport",
so that we won't end up with lots of reindentation to do.)
> Magic return statements hidden inside macros seem not too fun. What
> I'd like to see is a macro that takes a pointer to an ErrorData and
> the rest of the arguments like ereport() and stuffs everything in
> there. And then you can pass that to ThrowErrorData() later if you
> like. That way it's visible when you're using the macro where you're
> putting the error. I think that would make the code more readable.
I think that'd just complicate the places that are having to report
such errors --- of which there are likely to be hundreds by the time
we are done. I will not accept a solution that requires more than
the absolute minimum of additions to the error-reporting spots.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, andrew@dunslane.net, corey.huinker@gmail.com, n.gluhov@postgrespro.ru, pgsql-hackers@lists.postgresql.org
Subject: Re: Error-safe user functions
In-Reply-To: <1695760.1669923671@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox