Re: EmitWarningsOnPlaceholders is too quiet

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: EmitWarningsOnPlaceholders is too quiet
Date: 2009-01-05 21:31:04
Message-ID: 26710.1231191064@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> I rememebered what INFO is for: it's the elevel that VACUUM VERBOSE
> uses to ensure that its output gets seen at the client. (I missed
> that in my first grep because vacuum's elog/ereport calls don't use
> INFO as a hard-wired elevel.) So we probably can't get rid of it.
> But that makes it even more clear IMHO that EmitWarningsOnPlaceholders
> shouldn't be using it. It's not intended for error/warning types of
> uses, but for verbose logging.

After a more careful grep, here are all the uses of INFO elog level:

VACUUM/ANALYZE/CLUSTER VERBOSE
NOTIFY, in a standalone backend
guc.c's set_config_option, to bleat about bad config settings obtained from
ALTER USER or ALTER DATABASE during connection startup
guc.c's EmitWarningsOnPlaceholders, to bleat about bad custom variables

Also, most of the PLs have ways for users to emit messages at INFO
elevel, but whether a user uses that in a consistent way is not our
problem.

I'm of the opinion that guc.c is in error here, and what it should be
using for its purposes is WARNING. Objections?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martin Pihlak 2009-01-05 21:42:23 Re: SQL/MED compatible connection manager
Previous Message Lee McKeeman 2009-01-05 21:25:38 Re: Status of issue 4593