Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > I can create a global variable to control this, but the new elog level
> > seemed cleaner.
> What I don't like about the proposed patch is that it's nonorthogonal.
> I see no reason to suppose that LOG is the only possible elevel for
> which it might be interesting to suppress the STATEMENT: field.
> Perhaps the best thing would be to define an additional ereport
> auxiliary function, say errprintstmt(bool), that could set a flag
> in the current elog stack entry to control suppression of STATEMENT.
> This would mean you couldn't determine the behavior when using elog(),
> but that's not supposed to be used for user-facing messages anyway.
One idea I had was to set the high-bit of elevel to control whether we
want to suppress statement logging, but I think errprintstmt() might be
best. I don't understand the ereport stack well enough to add this
functionality, though. What should I look for?
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
+ If your life is a hard drive, Christ can be your backup. +
In response to
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2007-03-02 22:12:39|
|Subject: Re: proposal: only superuser can change customized_options|
|Previous:||From: Joshua D. Drake||Date: 2007-03-02 21:44:30|
|Subject: Re: [HACKERS] WITH/RECURSIVE plans|
pgsql-patches by date
|Next:||From: Tom Lane||Date: 2007-03-02 22:37:33|
|Subject: Re: [HACKERS] Deadlock with pg_dump? |
|Previous:||From: Jeremy Drake||Date: 2007-03-02 21:47:50|
|Subject: cosmetic patch to large object regression test|