
> > My take was to have WARNING and NOTICE, yours is WARNING and INFO ?
> > For me INFO is also better to understand than NOTICE.
> > Not sure that alone is worth the change though, since lots of 
> > clients will currently parse "NOTICE".
> 
> OK, now that the current elog() patch seems to be OK with everyone, we
> can discuss if we want to change the remaining non-INFO NOTICE messages
> to WARNING.  Seems to more closely match the SQL standard. All messages
> will continue using the 'N' protocol type so this shouldn't be an issue.

Yes, I think that would be good.

> I don't know any clients that parse the NOTICE: tag, but they are going
> to have to change things for INFO: anyway so we might as well make the
> change during 7.3 too.

Good point.

> > I also like LOG, since I don't like the current NOTICES in the log.
> 
> Good, that was one of my goals.
> 
> > Imho INFO and WARNING would be nothing for the log per default.
> > LOG would be things that are only of concern to the DBA.
> > My preferred client level would prbbly be WARNING (no INFO).
> 
> Well, that is interesting.  Currently we would send WARNING/NOTICE to
> the logs because it is an exceptional condition, though not as serious
> as error.

Well, string truncation is imho not for the log, might interest the app
programmer but probably not the dba ? And if your point was to get rid 
of the notices in the log (as is mine) you would have to not log Warning, 
no ?

Andreas

Fri, 1 Mar 2002 19:37:33 +0100
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: elog() patch
> > > I also like LOG, since I don't like the current NOTICES in the log.
> > 
> > Good, that was one of my goals.
> > 
> > > Imho INFO and WARNING would be nothing for the log per default.
> > > LOG would be things that are only of concern to the DBA.
> > > My preferred client level would prbbly be WARNING (no INFO).
> > 
> > Well, that is interesting.  Currently we would send WARNING/NOTICE to
> > the logs because it is an exceptional condition, though not as serious
> > as error.
> 
> Well, string truncation is imho not for the log, might interest the app
> programmer but probably not the dba ? And if your point was to get rid 
> of the notices in the log (as is mine) you would have to not log Warning, 
> no ?

OK, now things could get complicated.  If we don't want to see
NOTICE/WARNING in the log, you could say you don't want to see ERROR in
the log, particularly syntax errors.  Where do we go from here?  You
could set your server_min_messages to FATAL, but then you don't see LOG
messages about server startup.

I have considered allowing individual message types to be specified,
particularly for the server logs, but the user API for that,
particilarly as SET from psql, becomes very complicated.

Maybe I have the ordering wrong for server_min_messages.  Perhaps it
should be:

	DEBUG5-1, INFO, NOTICE/WARNING, ERROR, LOG, FATAL, PANIC

Nothing prevents us from doing that.  Well, anyway, not sure how much I
like it but I throw it out as an idea.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 1 Mar 2002 13:50:03 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: elog() patch
Zeugswetter Andreas SB SD wrote:
> 
> > > My take was to have WARNING and NOTICE, yours is WARNING and INFO ?
> > > For me INFO is also better to understand than NOTICE.
> > > Not sure that alone is worth the change though, since lots of 
> > > clients will currently parse "NOTICE".
> > 
> > OK, now that the current elog() patch seems to be OK with everyone, we
> > can discuss if we want to change the remaining non-INFO NOTICE messages
> > to WARNING.  Seems to more closely match the SQL standard. All messages
> > will continue using the 'N' protocol type so this shouldn't be an issue.
> 
> Yes, I think that would be good.

OK, now that the elog() patch is in, we can discuss NOTICE.  I know
Peter wants to keep NOTICE to reduce the number of changes, but I
already have a few votes that the existing NOTICE messages should be
changed to a tag of WARNING.  I have looked through the NOTICE elog
calls, and they all appear as warnings to me --- of course with the
informative messages now INFO, that is no surprise.

I realize the change will be large, ~240 entries, but we are doing
elog() changes right now, and I think this is a good time to do it.  It
is more informative, and closer to SQL standard.  The priority of NOTICE
will not change, it will just be called WARNING in the code and as sent
to the user.  I did look at keeping both NOTICE and WARNING but didn't
see any value in both of them.  NOTICE was sufficiently generic to
handle info and warning message, but now that we have INFO, NOTICE just
doesn't seem right and WARNING makes more sense.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 3 Mar 2002 18:03:41 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: elog() patch
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, now that the elog() patch is in, we can discuss NOTICE.  I know
> Peter wants to keep NOTICE to reduce the number of changes, but I
> already have a few votes that the existing NOTICE messages should be
> changed to a tag of WARNING.

If you're taking a vote, I vote with Peter.  I don't much care for the
thought of EXPLAIN results coming out tagged WARNING ;-)

In any case, simple renamings like this ought to be carried out as part
of the prefix-tagging of elog names that we intend to do late in 7.3,
no?  I see no value in having two rounds of widespread changes instead
of just one.

			regards, tom lane

Sun, 03 Mar 2002 21:02:54 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: elog() patch 
EXPLAIN would come out as INFO would it not?

--
Rod Taylor

This message represents the official view of the voices in my head

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>;
<pgsql-hackers@postgresql.org>
Sent: Sunday, March 03, 2002 9:02 PM
Subject: Re: [HACKERS] elog() patch


> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > OK, now that the elog() patch is in, we can discuss NOTICE.  I
know
> > Peter wants to keep NOTICE to reduce the number of changes, but I
> > already have a few votes that the existing NOTICE messages should
be
> > changed to a tag of WARNING.
>
> If you're taking a vote, I vote with Peter.  I don't much care for
the
> thought of EXPLAIN results coming out tagged WARNING ;-)
>
> In any case, simple renamings like this ought to be carried out as
part
> of the prefix-tagging of elog names that we intend to do late in
7.3,
> no?  I see no value in having two rounds of widespread changes
instead
> of just one.
>
> regards, tom lane
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
majordomo@postgresql.org
>


Sun, 3 Mar 2002 21:18:09 -0500
"Rod Taylor" <rbt@zort.ca>
Re: elog() patch 
"Rod Taylor" <rbt@zort.ca> writes:
> EXPLAIN would come out as INFO would it not?

If we make it INFO it won't come out at all, at the message level that
a lot of more-advanced users will prefer to use.  That's no solution.

			regards, tom lane

Sun, 03 Mar 2002 21:23:40 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: elog() patch 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > OK, now that the elog() patch is in, we can discuss NOTICE.  I know
> > Peter wants to keep NOTICE to reduce the number of changes, but I
> > already have a few votes that the existing NOTICE messages should be
> > changed to a tag of WARNING.
> 
> If you're taking a vote, I vote with Peter.  I don't much care for the
> thought of EXPLAIN results coming out tagged WARNING ;-)

EXPLAIN now comes out as INFO.

> In any case, simple renamings like this ought to be carried out as part
> of the prefix-tagging of elog names that we intend to do late in 7.3,
> no?  I see no value in having two rounds of widespread changes instead
> of just one.

Agreed.  So you think WARNING makes sense, but let's do it at the right
time.  Perhaps that is what Peter was saying anyway.

However, with DEBUG symbol gone, or at least gone after 7.3, I don't see
a big need to add PG_ to the beginning of every elog() symbol.  Can I
get some votes on that?  DEBUG was our big culprit of conflict with
other interfaces, specifically Perl.  With that split into DEBUG1-5, do
we need to prefix the remaining symbols?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 3 Mar 2002 21:49:07 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: elog() patch
Tom Lane wrote:
> "Rod Taylor" <rbt@zort.ca> writes:
> > EXPLAIN would come out as INFO would it not?
> 
> If we make it INFO it won't come out at all, at the message level that
> a lot of more-advanced users will prefer to use.  That's no solution.

Well, right now it is INFO.  It is certainly not a notice/warning or
error.  Seems we will have to address this.  Let me look at the existing
INFO message and see if there are any others that _have_ to be emitted. 
I will add a new symbol INFOFORCE which will always be sent to the
client no matter what the client_min_messages level.   Seems this is the
only good way to fix this.  Even if we make that NOTICE/WARNING, people
may turn that off too.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 3 Mar 2002 21:52:52 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: elog() patch
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I will add a new symbol INFOFORCE which will always be sent to the
> client no matter what the client_min_messages level.

I was thinking along the same lines, but I hate that name.
INFOALWAYS maybe?

Also, should it be different from INFO as far as the server log
goes?  Not sure.

			regards, tom lane

Sun, 03 Mar 2002 22:22:22 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: elog() patch 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I will add a new symbol INFOFORCE which will always be sent to the
> > client no matter what the client_min_messages level.
> 
> I was thinking along the same lines, but I hate that name.
> INFOALWAYS maybe?

Love it.  :-)  Sounds like a song.  Info-always on my mind, ...

> Also, should it be different from INFO as far as the server log
> goes?  Not sure.

No, I think we add too much confusion doing that.  It should behave like
info to the server or we have to add an additional server_min_messages
level.  My feeling is that they would want INFOALWAYS in server logs in
the same cases they would want INFO.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 3 Mar 2002 22:24:24 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: elog() patch
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> However, with DEBUG symbol gone, or at least gone after 7.3, I don't see
> a big need to add PG_ to the beginning of every elog() symbol.  Can I
> get some votes on that?  DEBUG was our big culprit of conflict with
> other interfaces, specifically Perl.

Wrong: ERROR is a problem too.  And if you think that INFO or WARNING
or PANIC will not create new problems, you are a hopeless optimist.

We are already forcing renamings of a lot of elog symbols (eg, NOTICE
and DEBUG), so we may as well go the extra step and actually solve the
problem, rather than continue to ignore it.

BTW, I'd go with PGERROR etc, not PG_ERROR, just to save typing.

			regards, tom lane

Sun, 03 Mar 2002 22:26:45 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: elog() patch 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > However, with DEBUG symbol gone, or at least gone after 7.3, I don't see
> > a big need to add PG_ to the beginning of every elog() symbol.  Can I
> > get some votes on that?  DEBUG was our big culprit of conflict with
> > other interfaces, specifically Perl.
> 
> Wrong: ERROR is a problem too.  And if you think that INFO or WARNING
> or PANIC will not create new problems, you are a hopeless optimist.
> 
> We are already forcing renamings of a lot of elog symbols (eg, NOTICE
> and DEBUG), so we may as well go the extra step and actually solve the
> problem, rather than continue to ignore it.
> 
> BTW, I'd go with PGERROR etc, not PG_ERROR, just to save typing.

OK, unless someone else responds, we will go with PG* and
NOTICE->WARNING near 7.3 beta start when tree is quiet.  We will keep
old symbols around for 7.3 release.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 3 Mar 2002 22:28:55 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: elog() patch
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I will add a new symbol INFOFORCE which will always be sent to the
> > client no matter what the client_min_messages level.
> 
> I was thinking along the same lines, but I hate that name.
> INFOALWAYS maybe?
> 
> Also, should it be different from INFO as far as the server log
> goes?  Not sure.

In going over the existing INFO messages, I now see that there are
several places that must send messages to the client no matter what
client_min_messages is set to.  The areas are EXPLAIN, VACUUM, ANALYZE,
SHOW, and various "unsuported" messages.

So, I am now thinking that INFOALWAYS is not the proper way to handle
these cases.  While I saw no value in splitting the current NOTICE
messagees into WARNING and NOTICE (they all seem pretty much the same),
I now see a value in splitting INFO into INFO for "always to client" and
NOTICE which will be things like automatic sequence creation.

So, based on current CVS, NOTICE -> WARNING, and some INFO will be
changed to NOTICE and remaining INFO will always be sent to the client.

If I don't create a new tag, then people who set the client_min_messages
to ERROR will be confused to see INFO messages in some cases and not
others.  In the final code, client_min_messages will not have an INFO
level option because INFO will always go to the client. 
server_min_messages will have an INFO option.

Comments?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 4 Mar 2002 14:32:25 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: elog() patch
OK, I talked to Tom on the phone and here is what I would like to do:

o  Change all current CVS messages of NOTICE to WARNING.  We were going
to do this just before 7.3 beta but it has to be done now, as you will
see below.

o Change current INFO messages that should be controlled by
client_min_messages to NOTICE.

o Force remaining INFO messages, like from EXPLAIN, VACUUM VERBOSE, etc.
to always go to the client.

o Remove INFO from the client_min_messages options and add NOTICE.

Seems we do need three non-ERROR elog levels to handle the various
behaviors we need for these messages.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 4 Mar 2002 15:46:56 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: elog() patch

Changes committed.  Regression passes. We now have three elog levels to
client, INFO for always to client, NOTICE for tips, and WARNING for
non-error problems.  See elog.h for discription.


---------------------------------------------------------------------------

Bruce Momjian wrote:
> OK, I talked to Tom on the phone and here is what I would like to do:
> 
> o  Change all current CVS messages of NOTICE to WARNING.  We were going
> to do this just before 7.3 beta but it has to be done now, as you will
> see below.
> 
> o Change current INFO messages that should be controlled by
> client_min_messages to NOTICE.
> 
> o Force remaining INFO messages, like from EXPLAIN, VACUUM VERBOSE, etc.
> to always go to the client.
> 
> o Remove INFO from the client_min_messages options and add NOTICE.
> 
> Seems we do need three non-ERROR elog levels to handle the various
> behaviors we need for these messages.
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 6 Mar 2002 01:11:20 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: elog() patch