Fabien COELHO <coelho@cri.ensmp.fr> writes:
>> In particular, we determined that the appropriate place for this sort of
>> thing is on the client side, not in the backend.
> The current status of clients is that none of those I use will report
> anything useful.
So fix the clients. We have been through this discussion before; you
are not the first to claim we should do a quick-and-dirty solution on
the backend side. That wasn't the consensus then, and I don't think
it is now.
>> I think the odds of doing anything very successful in the way of syntax
>> hints are small. The cases where you can produce a reliable hint (ie,
>> one that's not likely to be misleading) are not very interesting.
> This is an a-priori jugement.
> 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.
>> I am not understanding what you have against the existing error context
>> stack mechanism.
> 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.
> 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. The context hooks
are installed and removed as if on a stack, but we don't form an error
string until an error actually occurs. At that point, stringing
together the outputs of the active hooks is the correct thing to do.
regards, tom lane
