Re: Unified logging system for command-line programs - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Unified logging system for command-line programs
Date
Msg-id 20190103180315.o4gh3id5quh5aebc@alap3.anarazel.de
Whole thread Raw
In response to Re: Unified logging system for command-line programs  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Unified logging system for command-line programs
List pgsql-hackers
Hi,

On 2019-01-03 14:28:51 +0100, Peter Eisentraut wrote:
> On 31/12/2018 16:55, Andres Freund wrote:
> > I think we should aim to unify the use (in contrast to the
> > implementation) of logging as much as possible, rather than having a
> > separate API for it for client programs.
> 
> I opted against doing that, for mainly two reasons: One, I think the
> ereport() API is too verbose for this purpose, an invocation is usually
> two to three lines.

Well, then elog() could be used.


> My goal was to make logging smaller and more
> compact.  Two, I think tying error reporting to flow control does not
> always work well and leads to bad code and a bad user experience.

Not sure I can buy that, given that we seem to be doing quite OK in the backend.


> Relatedly, rewriting all the frontend programs to exception style would
> end up being a 10x project to rewrite everything for no particular
> benefit.  Going from 8 or so APIs to 2 is already an improvement, I
> think.  If someone wants to try going further, it can be considered, but
> it would be an entirely different project.

Why would it be 10x the effort, if you already touch all the relevant
log invocations? This'll just mean that the same lines will
mechanically need to be changed again.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Logical decoding for operations on zheap tables
Next
From: Alvaro Herrera
Date:
Subject: Re: Logical decoding for operations on zheap tables