Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> M Message --- the string is the primary error message (localized).
>> D Detail --- secondary error message, carrying more detail about
>> the problem (localized).
>> H Hint --- a suggestion what to do about the error (localized).
> Client interfaces for the most part only have the notion of a single
> "message text". (And keep in mind that the definitions of most interfaces
> are outside our control: JDBC, ODBC, ECPG, Perl DBI, PHP, etc.) So what
> kind of functionality is needed so that standardized interfaces can get at
> any of the provided details and hints?
I think this is a matter to be solved at the level of the API of each
client library. For example, libpq's PQerrorMessage would presumably
construct some unified string out of these three fields and the error
severity; plus we'd add new calls to extract the individual fields.
I do not think it's appropriate to try to control this from the server
side of things.
> Also, how do we control what amount of detail is written to the server
> log?
Some GUC variables would do for that, probably, if we think it's a good
idea to be selective (a proposition I'm dubious about).
regards, tom lane
