Re: pgsql: Mark the second argument of pg_log as the translatable string in

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: hlinnaka(at)iki(dot)fi
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Fujii Masao <fujii(at)postgresql(dot)org>, pgsql-committers <pgsql-committers(at)postgresql(dot)org>
Subject: Re: pgsql: Mark the second argument of pg_log as the translatable string in
Date: 2015-04-15 12:15:57
Message-ID: CAB7nPqQ7BuQMUd8Ab=do69UVsjhzEQjW5usSc_1gBnmgMMSTJQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On Wed, Apr 15, 2015 at 4:55 PM, Heikki Linnakangas wrote:
> On 04/15/2015 06:41 AM, Fujii Masao wrote:
>> Another question is; should we output the progress report to stderr rather
>> than stdout? I thought this because I found that pg_basebackup reports
>> the progress to stderr.
>
>
> Yeah, probably. We should go through all the output and figure out where
> each kind of message needs to do. Should follow the principle Alvaro laid
> out
> (http://www.postgresql.org/message-id/20150407205320.GN4369@alvh.no-ip.org),
> and also make sure it's consistent with pg_basebackup and other tools.
> Michael's patch changed some of the logging but we should take a more
> holistic look at the situation. And add a comment somewhere explaining the
> principle.

Isn't what we are looking for here a common set of frontend-only APIs,
let's say as src/common/logging.c? All the tools we have could use it
without knowing if they output on stdout and stderr.
--
Michael

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Michael Paquier 2015-04-15 12:31:42 Re: [COMMITTERS] pgsql: Move pg_upgrade from contrib/ to src/bin/
Previous Message Peter Eisentraut 2015-04-15 10:54:21 Re: [COMMITTERS] pgsql: Move pg_upgrade from contrib/ to src/bin/