From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, <pgsql-interfaces(at)postgreSQL(dot)org> |
Subject: | Re: [INTERFACES] Upgrading the backend's error-message infrastructure |
Date: | 2003-03-18 14:36:03 |
Message-ID: | Pine.LNX.4.44.0303181522330.2003-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-interfaces |
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?
Maybe this doesn't need to be solved at the protocol layer. Instead a
server-side switch regulates the detail of the provided messages.
Also, how do we control what amount of detail is written to the server
log?
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Nigel J. Andrews | 2003-03-18 14:37:52 | Re: Primary key and references |
Previous Message | Peter Eisentraut | 2003-03-18 14:35:38 | Re: [INTERFACES] Upgrading the backend's error-message infrastructure |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-03-18 14:44:32 | Re: [INTERFACES] Upgrading the backend's error-message infrastructure |
Previous Message | Peter Eisentraut | 2003-03-18 14:35:38 | Re: [INTERFACES] Upgrading the backend's error-message infrastructure |