Re: Missing errcode() in ereport

Andres Freund <andres(at)anarazel(dot)de> writes:
> I wondered before whether there's a way we could move the elevel check
> in errstart to the macro. For it to be a win we'd presumably have to
> have a "synthesized" log_level variable, basically
> min(log_min_messages, client_min_messages, ERROR).
> Probably not worth it.

Yeah, I don't really agree with that idea. The whole business of which
elevels will trigger output is fundamentally policy, not mechanism,
and you do not want policy decisions embedded into ABI so that there
are hundreds of copies of them. It's a loss for code size and a worse
loss if you ever want to change the behavior.

> On 2020-03-23 17:24:49 -0400, Tom Lane wrote:
>> One thing I'm not totally sure about is whether we can rely on
>> this change:
>>
>> -extern void errfinish(int dummy,...);
>> +extern void errfinish(void);
>>
>> being fully ABI-transparent. One would think that as long as errfinish
>> doesn't inspect its argument(s) it doesn't matter whether any are passed,
>> but maybe somewhere there's an architecture where the possible presence
>> of varargs arguments makes for a significant difference in the calling
>> convention? We could leave that change out of the v12 patch if we're
>> worried about it.

> I would vote for leaving that out of the v12 patch. I'm less worried
> about odd architectures, and more about sanitizers and/or compilers
> emitting "security enhanced" code checking signatures match etc
> ("control flow integrity").

Yeah, good point. Let's skinny the v12 patch down to just macro
and docs changes, then, not touching elog.c at all.

I made a commitfest entry for this just to see what the cfbot
thinks of it, but if there are not objections we should go ahead
and push in a day or so, IMO.

regards, tom lane

BTW, the CF app is showing me as the first author, even though
I definitely put you in first. Guess it doesn't care about
author ordering ... is that a bug to be fixed?