Re: Error message style guide, take 2
От | Tom Lane |
---|---|
Тема | Re: Error message style guide, take 2 |
Дата | |
Msg-id | 26944.1053094413@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Error message style guide, take 2 (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Error message style guide, take 2
|
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > This is slightly unrelated, but what kind of switches should client > libraries have to control the level of detail that the application sees? Not sure ... feel free to make a proposal. I had been planning to add function(s) to libpq to allow individual error fields to be extracted, but you are right that there'll need to be some way to customize the behavior of PQerrorMessage() as well. > And I think I do want the detail in the server log, too. I had been thinking that it might be useful to have something corresponding to min_log_level, ie "show details if error level >= X". (I'm thinking that the one switch would control logging of all details, ie, everything but the primary error message.) I'm not completely happy with that though, because of two thoughts: (1) We probably want details always for anything that prevents postmaster startup --- for instance, all that hard-won verbiage about shmem configuration problems will never be seen again if the default is not to put it into the postmaster log. (2) On the other hand, there are a lot of perfectly ordinary and uninteresting "FATAL" conditions during backend start --- misspelled database name, for example. The default should not include logging details for these. Perhaps we could put in some hack to vary the logging level depending on whether we are in postmaster start, postmaster run, backend start, backend run state. Not sure though. Any ideas? regards, tom lane
В списке pgsql-hackers по дате отправления: