From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
cc: robertmhaas@gmail.com, pgsql-hackers@lists.postgresql.org,
        peter.eisentraut@enterprisedb.com
Subject: Re: Frontend error logging style
In-reply-to: <20211111.110755.186485829988584825.horikyota.ntt@gmail.com>
References: 
 <CA+TgmoZjmJF0bTfd_q7yXWCR9cp0n6XgBHM7XPPy7R9jSWrJCQ@mail.gmail.com>
 <1442862.1636560925@sss.pgh.pa.us> <1455731.1636572308@sss.pgh.pa.us>
 <20211111.110755.186485829988584825.horikyota.ntt@gmail.com>
Comments: In-reply-to Kyotaro Horiguchi <horikyota.ntt@gmail.com>
	message dated "Thu, 11 Nov 2021 11:07:55 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1492692.1636597228.1@sss.pgh.pa.us>
Date: Wed, 10 Nov 2021 21:20:28 -0500
Message-ID: <1492693.1636597228@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1492693.1636597228%40sss.pgh.pa.us>
Precedence: bulk

Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> Aren't DETAIL and HINT expected to be hidden at the targetted cutoff
> level?  In other words, I suspect that people want to hide non-primary
> messages for a lower verbosity level.  On the other hand I'm not sure
> it is a proper behavior that log_level = WARNING causes ERROR messages
> are accompanied by DETAIL/HINT submessages...

I abandoned that idea in the draft patch.  We could maybe do something
about it further down the line, but I'm not sure there's really any
demand.

As the patch is set up, you could theoretically do something like

	pg_log_error("blah blah");
	pg_log_info_detail("Very boring detail goes here.");

(note the intentionally different log priorities).  But that feels wrong
to me --- it doesn't seem like individual call sites should be setting
such policy.  If we do arrange for a way to hide the optional message
parts, I'd rather that the control were centralized in logging.c.

It certainly wouldn't be hard for logging.c to make different decisions
about what to print; the thing that's not clear to me is what the
user-level knob for it should look like.  We already used up the
option of more or fewer -v switches.

			regards, tom lane