Dear Tom,
> > I hope this is not ground to reject any patch without a try.
>
> No, but it will be a likely reason for rejecting the patch *after*
> trying it ;-). Consider yourself warned that the first thing I'll
> do is try to make the patch produce misleading hints.
With this approach, you can remove ALL hints from postgres, as I'm pretty
sure *you* can "build up" cases where any hint does not give the actual
solution.
The question is whether the hint might be useful in most/lot of cases...
if not, then I agree it should not be there. if yes, then it is better
than the current nothing.
So I'm okay for any "fair" trial;-)
Anyway I'll make a proof of concept implementation on one command and
submit as it a test case before going into an full implementation.
> > About the "context" field, I have seen in my quick browsing is how one can
> > add information to it, but I haven't seen (yet) how to remove some
> > information to put some other in place.
>
> Why would you want to? Removing available information is never correct.
I tried to explain it with little drawing in the mail.
The idea is that as the code is running, going up and down the call
stack, a "context stack" is constantly updated to reflect what is
being done for the user at the moment, when the information is
available to a function...
If no error occurs, then the context information is never used.
If an error occurs somewhere deep in the code, then the stack helps
describe the "user oriented" context of the current processing from which
the exception was raised. The deep function does not need to know
what was actually going on above to do that.
> > What is really needed is indeed a context stack in the error stack, and
> > what I've seen is a simple string in the error stack, where contexts are
> > appended one to the other at the string level.
>
> I think you're misinterpreting what the code does.
That's really possible, I only had a quick look at the source.
--
Fabien Coelho - coelho@cri.ensmp.fr