On 2004.03.04 17:19 Greg Stark wrote:
> Greg Stark <gsstark@MIT.EDU> writes:
>
> > It's great to know which constraint was violated but that doesn't
> really help
> > you figure out *why* it was violated.
>
> On further thought it would never be feasible to do what the other
> poster is
> really looking for. At least for table constraints it would require
> poking
> through the expression to determine which columns might have caused
> the
> violation.
This is exactly the kind of thing that exception handling mechanisims
with throws, catches, and first class continuations are great for.
Even without continuations, each exception handler can translate the
error it catches into something appropriate at the current level
of abstraction, what went wrong from it's perspective,
it means to the result that will be produced, and what
steps might be taken to avoid the problem. If each layer
of abstraction, application, SQL, constraint, etc., takes the care
to catch it's errors and pass them on you wind up with an
annoted stack trace, the topmost level of which should be
meaningful to the end-user.
Of course most programmers don't bother to even check for error
conditons
when they are returned as results, so it's probably too
much to expect that the users will ever get good errors,
but it should be possible for postgresql to deliver something
of a stack trace. ?
BTW, I like the idea of two classes of error messages, one to be
logged for the DBA and one for the user.
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein