At 11:12 22-02-00 -0500, Tom Lane wrote:
>Jeroen van Vianen <jeroen@design.nl> writes:
> > What I see now is something like this (for psql):
>
> > psql sends a query
> > psql reads response
> > if response is error
> > get error location and find context in which error
> occurred
> > print error message, with error location and context
> > otherwise
> > do what it used to do
>
> > and for the other interfaces nothing changes.
>
> > This is something I might be able to implement for 7.1.
>
>This looks much better to me than doing it in the backend. What still
>needs a little thought is how to send back the error location from
>backend to client app.
>
>I'd be inclined to say that the location info should be imbedded as
>text in the existing textual error message, rather than trying to add
>a separate message with a machine-readable location value. The first
>way is much less likely to create compatibility problems with old client
>apps. One way to do it is to say that if the last line of the error
>message looks like
>
>Error-location: nnn
>
>then libpq should recognize that, strip the line out of the saved
>textual error message, and make the location value available through
>a new API call.
Isn't it possible to get this kind of information from a call to a new API
struct errorinfo * PQerrorInfo(conn) where the struct contains info about
the error message, location and code, rather than a call to
PQerrorMessage(conn) ?
>The reason I suggest a label is that we could further extend this
>protocol to handle some other things that people have been griping
>about for a long time: providing identifying error code numbers that
>client code could rely on instead of trying to match against the error
>text, and separating out the info about which routine generated the
>error (which is mighty handy for backend debugging but is useless
>info for Joe Average user). Someday the message being sent back
>might look less like
>
>ERROR: relation_info: Relation 12345 not found
>
>and more like
>
>ERROR: Failed to find relation OID 12345 in system catalogs
>Error-code: 4242
>Reporting-routine: relation_info, plancat.c line 543
>
>of which only the first line is really meant for the user.
This might even allow the client app to write out a customized error
message, instead of 'foreign key ... violation' write 'You cannot delete
any ... when there are still ...', based upon error codes.
>Of course, making that happen will be a lot of work, and I'm not
>asking you to volunteer for it. But what you do now should fit
>in with further development of the error handling stuff...
Jeroen