Re: elog() patch - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: elog() patch
Date
Msg-id 200203011642.g21Ggdm08789@candle.pha.pa.us
Whole thread Raw
In response to Re: elog() patch  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
List pgsql-hackers
Zeugswetter Andreas SB SD wrote:
> 
> > > We could call it TIP or something like that. I think INFO is used
> > > because it isn't a NOTICE or ERROR or something major.  It is only INFO.
> > > It is neutral information.
> > 
> > That's what NOTICE is.  NOTICE is only neutral information. NOTICE could
> > go to the client by default, whereas if you want something in the server
> > log you use LOG.  I doubt an extra level is needed.
> 
> SQL92 has WARNING, would that be a suitable addition to NOTICE ?
> INFO would not be added since it is like old NOTICE which would stay.
> So, instead of introducing a lighter level we would introduce a 
> stronger level. (WARNING more important than NOTICE) 
> If we change, we might as well adopt some more SQL'ism. 
> 
> e.g. string truncation is defined to return SUCCESS with WARNING.
> 
> I guess it would be a horror for existing client code though :-(

Actually, an interesting idea would be to leave NOTICE alone and make
the more serious messages WARNING.  The problem with that is I think
INFO is clearer as something for client/user, and LOG something for the
logs.  I don't think NOTICE has the same conotation.  I just thought I
would mention that possibility.

So, with WARNING, NOTICE would go away and become INFO or WARNING, and
DEBUG goes away to become DEBUG1-5.  With DEBUG gone, our need to add
PG_* to the beginning of the elog symbols may not be necessary.

--  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,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: Bug #605: timestamp(timestamp('a timestamp)) no longer works
Next
From: Stephan Szabo
Date:
Subject: Re: Database Caching