Re: elog() patch
От | Bruce Momjian |
---|---|
Тема | Re: elog() patch |
Дата | |
Msg-id | 200203032303.g23N3f315423@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: elog() patch ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>) |
Ответы |
Re: elog() patch
|
Список | pgsql-hackers |
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, Pennsylvania19026
В списке pgsql-hackers по дате отправления: