Hi, On 2020-03-30 11:54:03 +0800, Craig Ringer wrote: > On Fri, 20 Mar 2020, 01:59 Andres Freund, <and...@anarazel.de> wrote: > > 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.
IDK, that seems like it'll be a bit too implementation specific. > 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 . Well, they can do whatever they can in any function argument list. I don't see why the ereport docs are a good place to explain ... ? ... : ... ? Or am I misunderstanding what you suggest here? > Not sure there's much we can do without changing ereport's "signature" I think the changes we just did already improved the situation a good bit. Both by obviating the need for the additional parentheses, as well as making parameters outside of err*() trigger warnings, and also generally better error/warning messages. I still think we might want to do a bigger change of the logging APIs. See the messages leading up to https://postgr.es/m/20190805214952.dmnn2oetdquixpp4%40alap3.anarazel.de and the message linked from there. Greetings, Andres Freund
