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.
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.
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...
regards, tom lane
