Peter Eisentraut writes:
> It looks like there is documentation for PG_COLORS in the release notes
> now, which seems like an odd place. Suggestions for a better place?
BTW, as far as that goes, it looks like PG_COLOR is documented separately
in each frontend program's "Environment" man page sec
Peter Eisentraut writes:
> On 2019-06-06 11:08, Masahiko Sawada wrote:
>>> Do we need two variables to control this? I was only looking at
>>> PG_COLOR, and noticed PG_COLORS only later. Keeping PG_COLORS aligned
>>> with {GCC,LS}_COLORS makes sense. How about removing PG_COLOR, and
>>> making "au
On 2019-06-06 11:08, Masahiko Sawada wrote:
> On Tue, Apr 9, 2019 at 9:01 PM Christoph Berg wrote:
>>
>> Re: Peter Eisentraut 2019-04-09
>>
>>> I'm okay with changing it. As you indicate, I chose the name so that it
>>> doesn't look like a libpq variable. There are some other PG_ variables
>>>
On Tue, Apr 9, 2019 at 9:01 PM Christoph Berg wrote:
>
> Re: Peter Eisentraut 2019-04-09
>
> > I'm okay with changing it. As you indicate, I chose the name so that it
> > doesn't look like a libpq variable. There are some other PG_ variables
> > throughout the code, but those appear to be most
On 2019-04-09 13:58, Christoph Berg wrote:
> I'm not entirely sure what happened here, but I think this made
> pg_restore verbose by default (and there is no --quiet option).
That was by accident. Fixed.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 S
Re: Peter Eisentraut 2019-04-09
> I'm okay with changing it. As you indicate, I chose the name so that it
> doesn't look like a libpq variable. There are some other PG_ variables
> throughout the code, but those appear to be mostly for internal use.
> Also, there is GCC_COLORS, LS_COLORS, etc.
Re: Peter Eisentraut 2019-04-01
> - There is support for setting a "log level". This is not meant to be
> user-facing, but can be used internally to implement debug or
> verbose modes.
I'm not entirely sure what happened here, but I think this made
pg_restore verbose by default (and there is
On 2019-04-09 11:22, Christoph Berg wrote:
> Can we rename PG_COLOR to PGCOLOR? This is the only PG* environment
> variable prefixed with the extra underscore, and remembering that will
> be confusing. (Like pgbench should really be named pg_bench for
> consistency.) Even if it's not a libpq variab
Re: Peter Eisentraut 2019-04-01
> - Some color in the messages, similar to gcc and clang. Set
> PG_COLOR=auto to try it out. Some colors are predefined, but can be
> customized by setting PG_COLORS.
Can we rename PG_COLOR to PGCOLOR? This is the only PG* environment
variable prefixed with t
On 2019-Apr-02, Tom Lane wrote:
> Alvaro Herrera 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?
Actually, we don't
Alvaro Herrera 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 stri
I don't much like the code that does
pg_log_error("%s", something);
because then the string "%s" is marked for translation. 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(
On 2019-04-02 05:05, Michael Paquier wrote:
> I am a bit disappointed that this stuff is not reducing
> the amount of diff code with ifdef FRONTEND in src/common/.
That wasn't the purpose of the patch. If you have a concrete proposal
for how to do what you describe, it would surely be welcome.
-
On 2019-04-01 20:55, Andres Freund wrote:
> A written upthread, I think this should have had a uniform interface
> with elog.h, and probably even share some code between the two.
The purpose of this patch was to consolidate the existing zoo of logging
routines in the frontend programs. That has m
On Mon, Apr 01, 2019 at 11:55:09AM -0700, Andres Freund wrote:
> A written upthread, I think this should have had a uniform interface
> with elog.h, and probably even share some code between the two. This is
> going in the wrong direction, making it harder, not easier, to share
> code between front
On 2019-04-01 20:48:41 +0200, Peter Eisentraut wrote:
> On 2019-04-01 20:31, Andres Freund wrote:
> > I'm unhappy about this being committed. I don't think there was
> > terribly much buyin for this amount of duplicated infrastructure.
>
> What duplicated infrastructure?
A written upthread, I th
On 2019-04-01 20:31, Andres Freund wrote:
> I'm unhappy about this being committed. I don't think there was
> terribly much buyin for this amount of duplicated infrastructure.
What duplicated infrastructure?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24
df00ab582fed132e45c5745b1c38a4f59c9 Mon Sep 17 00:00:00 2001
> From: Peter Eisentraut
> Date: Fri, 22 Feb 2019 09:18:55 +0100
> Subject: [PATCH v3] Unified logging system for command-line programs
>
> This unifies the various ad hoc logging (message printing, error
> printing) sy
Hello,
On 22.02.2019 11:39, Peter Eisentraut wrote:
Here is an updated patch. I've finished the functionality to the point
where I'm content with it. I fixed up some of the remaining special
cases in pg_dump that I hadn't sorted out last time. I also moved the
scattered setvbuf(stderr, ...) h
> On Jan 11, 2019, at 9:14 AM, Peter Eisentraut
> wrote:
>
>> The patch cannot be applied directly on HEAD. So I patched it on top of
>> 60d99797bf.
>
> Here is an updated patch with the merge conflicts of my own design
> resolved. No functionality changes.
>
>> When I call pg_log_error()
I think this patch is a nice improvement!
On Jan 3, 2019, at 2:08 PM, Andres Freund wrote:
> Or we could just add an ERROR variant that doesn't exit. Years back
> I'd proposed that we make the log level a bitmask, but it could also
> just be something like CALLSITE_ERROR or something roughly alon
Hi,
On 2019-01-03 17:03:43 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 03/01/2019 22:01, Tom Lane wrote:
> >> while ereport(ERROR) has the
> >> effect of writing a message and then calling exit(1).
>
> > The problem is that in majority of cases the FRONTEND code, as it is
> > writte
Peter Eisentraut writes:
> On 03/01/2019 22:01, Tom Lane wrote:
>> while ereport(ERROR) has the
>> effect of writing a message and then calling exit(1).
> The problem is that in majority of cases the FRONTEND code, as it is
> written today, doesn't want to exit() after an error.
Right, so for th
On 03/01/2019 22:01, Tom Lane wrote:
> I envisioned that we'd have a wrapper in which
> non-error ereports() map directly onto what you're calling
> pg_log_debug, pg_log_warning, etc,
My code does that, but the other way around. (It's easier that way than
to unpack ereport() invocations.)
> whil
Peter Eisentraut writes:
> On 03/01/2019 19:03, Andres Freund wrote:
>>> 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.
On 03/01/2019 19:03, Andres Freund wrote:
>> 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
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 ag
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() AP
On 30/12/2018 20:45, Tom Lane wrote:
> It seems like a shame that src/common files still need to have
> #ifdef FRONTEND variant code to deal with frontend vs. backend
> conventions. I wonder how hard it would be to layer some subset of
> ereport() functionality on top of what you have here, so as
Ah, one more thing -- there's a patch by Marina Polyakova (in CC) to
make pgbench logging more regular. Maybe that stuff should be
considered now too. I'm not saying to patch pgbench in this commit, but
rather to have pgbench in mind while discussing the API. I think the
last version of that was
Hi,
On 2018-12-30 14:45:23 -0500, Tom Lane wrote:
> I wonder how hard it would be to layer some subset of
> ereport() functionality on top of what you have here, so as to get
> rid of those #ifdef stanzas.
+many. I think we should aim to unify the use (in contrast to the
implementation) of loggi
On 2018-Dec-30, Tom Lane wrote:
> Peter Eisentraut writes:
> > I have developed a patch that unifies the various ad hoc logging
> > (message printing, error printing) systems used throughout the
> > command-line programs.
>
> I've not read the patch in any detail, but +1 for making this more
> u
Peter Eisentraut writes:
> I have developed a patch that unifies the various ad hoc logging
> (message printing, error printing) systems used throughout the
> command-line programs.
I've not read the patch in any detail, but +1 for making this more
uniform.
> - Common files (common/, fe_utils/,
33 matches
Mail list logo
