From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>,
        Donald Dong <xdong@csumb.edu>, Andres Freund <andres@anarazel.de>
Subject: Re: Unified logging system for command-line programs
In-reply-to: <20190402195634.GA14682@alvherre.pgsql>
References: <20190402195634.GA14682@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Tue, 02 Apr 2019 16:56:34 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7473.1554236240.1@sss.pgh.pa.us>
Date: Tue, 02 Apr 2019 16:17:20 -0400
Message-ID: <7474.1554236240@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> I don't much like the code that does
>    pg_log_error("%s", something);

> because then the string "%s" is marked for translation.

Uh, surely we've got hundreds of instances of that in the system already?

> Maybe we should
> consider a variant that takes a straight string literal instead of a
> sprintf-style fmt to avoid this problem.  We'd do something like
>    pg_log_error_v(something);
> which does not call _() within.

What it looks like that's doing is something similar to appendPQExpBuffer
versus appendPQExpBufferStr, ie, just skipping the overhead of sprintf
format processing when you don't need it.  The implications for
translatability or not are unobvious, so I'm afraid this would result
in confusion and missed translations.

I'm not necessarily against some idea like this, but how do we
separate "translatability" from "sprintf formatting"?

			regards, tom lane