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
