Horton

Re: Missing errcode() in ereport

Craig Ringer <craig@2ndquadrant.com>

View thread View on postgr.es
From: Craig Ringer <craig@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Amit Kapila <amit.kapila16@gmail.com>, Michael Paquier <michael@paquier.xyz>, Julien Rouhaud <rjuju123@gmail.com>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-03-30T03:54:03Z
Lists: pgsql-hackers 
On Fri, 20 Mar 2020, 01:59 Andres Freund, <andres@anarazel.de> wrote:

> Hi,
>
> On 2020-03-17 10:09:18 -0400, Tom Lane wrote:
> > We might want to spend some effort thinking how to find or prevent
> > additional bugs of the same ilk ...
>
> Yea, that'd be good.  Trying to help people new to postgres write their
> first patches I found that ereport is very confusing to them - largely
> because the syntax doesn't make much sense. Made worse by the compiler
> error messages being terrible in many cases.


Very much agreed.

I'd have found it helpful to just have the docs explain clearly how it
works by chaining the comma operator using functions with ignored return
values.

That would also help people understand how they can make parts of an
ereport conditional, e.g. only set errdetail() if there additional info is
currently available W/O duplicating the rest of the ereport .


Not sure there's much we can do without changing ereport's "signature"
> though :(
>
> Regards,
>
> Andres
>
>
>

Commits

  1. Go back to returning int from ereport auxiliary functions.

  2. Improve the internal implementation of ereport().

  3. Re-implement the ereport() macro using __VA_ARGS__.

  4. Add missing errcode() in a few ereport calls.