From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Julien Rouhaud <rjuju123@gmail.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Missing errcode() in ereport
Date: Thu, 19 Mar 2020 19:12:04 -0700
Message-ID: <20200320021204.flrybgh4a7wltzye@alap3.anarazel.de> (raw)
In-Reply-To: <18567.1584666197@sss.pgh.pa.us>
References: <CAA4eK1KKmr-Dt-8=C=uoeKk7b6WqOTjjpMt_MXs4eFN1=kAX5w@mail.gmail.com>
<CAOBaU_bb7FR5cF9RKN42kPHf6pk9CeQ=wTuieJv-t3MroU_q0g@mail.gmail.com>
<20200317095839.GG2206@paquier.xyz>
<CAA4eK1+powcFw2EAoVgvH4P3fspAJhxU-VTy0_cR2XpcBZGMAA@mail.gmail.com>
<32174.1584454158@sss.pgh.pa.us>
<20200319175902.vjib2tslosw65iyr@alap3.anarazel.de>
<5063.1584641224@sss.pgh.pa.us>
<20200319230446.lxjybufdcgwaqkhj@alap3.anarazel.de>
<5995.1584660775@sss.pgh.pa.us>
<18567.1584666197@sss.pgh.pa.us>
Hi,
On 2020-03-19 21:03:17 -0400, Tom Lane wrote:
> I wrote:
> > I think that at least some compilers will complain about side-effect-free
> > subexpressions of a comma expression. Could we restructure things so
> > that the errcode/errmsg/etc calls form a standalone comma expression
> > rather than appearing to be arguments of a varargs function?
>
> Yeah, the attached quick-hack patch seems to work really well for
> this.
Heh, you're too fast. I just sent something similar, and a few followup
patches.
What is your thinking about pain around backpatching it might introduce?
We can't easily backpatch support for ereport-without-extra-parens, I
think, because it needs __VA_ARGS__?
> As a nice side benefit, the backend gets a couple KB smaller from
> removal of errfinish's useless dummy argument.
I don't think it's the removal of the dummy parameter itself that
constitutes most of the savings, but instead it's not having to push the
return value of errmsg(), errcode(), et al as vararg arguments.
> I think that we could now also change all the helper functions
> (errmsg et al) to return void instead of a dummy value, but that
> would make the patch a lot longer and probably not move the
> goalposts much in terms of error detection.
I did include that in my prototype patch. Agree that it's not necessary
for the error detection capability, but it seems misleading to leave the
return values around if they're not actually needed.
> It also looks like we could use the same trick to get plain elog()
> to have the behavior of not evaluating its arguments when it's
> not going to print anything. I've not poked at that yet either.
I've included a patch for that. I think it's now sufficient to
#define elog(elevel, ...) \
ereport(elevel, errmsg(__VA_ARGS__))
which imo is quite nice, as it allows us to get rid of a lot of
duplication.
Greetings,
Andres Freund
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: andres@anarazel.de, tgl@sss.pgh.pa.us, amit.kapila16@gmail.com, michael@paquier.xyz, rjuju123@gmail.com, masahiko.sawada@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Missing errcode() in ereport
In-Reply-To: <20200320021204.flrybgh4a7wltzye@alap3.anarazel.de>
* 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