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
Hi,
On 2019-02-22 09:39:59 +0100, 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(st
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/,
24 matches
Mail list logo
