Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages

From: Jeroen van Vianen <jeroen(at)design(dot)nl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages
Date: 2000-02-24 08:35:19
Message-ID: 4.2.2.20000222171620.00a9a100@mail.design.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 11:12 22-02-00 -0500, Tom Lane wrote:
>Jeroen van Vianen <jeroen(at)design(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jose Soares 2000-02-24 08:50:11 Re: [GENERAL] AW: [HACKERS] TRANSACTIONS
Previous Message Tom Lane 2000-02-24 05:45:56 Re: [HACKERS] Out of memory problem (forwarded bug report)