Horton

Re: Missing errcode() in ereport

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: 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-19T18:07:04Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> 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.

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

Now that we can rely on having varargs macros, I think we could
stop requiring the extra level of parentheses, ie instead of

        ereport(ERROR,
                (errcode(ERRCODE_DIVISION_BY_ZERO),
                 errmsg("division by zero")));

it could be just

        ereport(ERROR,
                errcode(ERRCODE_DIVISION_BY_ZERO),
                errmsg("division by zero"));

(The old syntax had better still work, of course.  I'm not advocating
running around and changing existing calls.)

I'm not sure that this'd really move the goalposts much in terms of making
it any less confusing, but possibly it would improve the compiler errors?
Do you have any concrete examples of crummy error messages?

			regards, tom lane

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.