> > (1) Lexical/syntax error source localisation > > > An extract of the offending source must be shown if possible along syntax > > error messages. > > You would do well to go to the archives and read some of the previous > discussion of these issues.
I'll do that. > 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. The server can use the DETAIL field (which is not used anyway) so as to give the details, and the client can chose to ignore it if it can do a better job. That would be providing a basic capability common to all clients, instead of waiting for a final implementation in all clients. > Only the client knows what is a reasonable way to mark the > error position. Sure. > > All generated error messages, especially from the parser, should be > > assorted with a HINT to help the user, if possible. Something like: > > 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. What I can do is take notice of all syntax errors from my students and use them as test cases to see what hint would help;-) I just have to turn on the database logs. > [...] That will be enough to cause you to deliver the wrong hint, > and a wrong hint is worse than none. I agree that if the hint are always wrong, then no hint is better. So in case we do not know, it is better not to say anything. However, I think that a lot of cases can be given good hints, and for those cases it should be done. Also, it is better to judge on the result. > ISTM that client-side code that pops up the syntax summary for the > command would probably accomplish far more, for far less work. > > We do have some hints for semantic errors, and adding more isn't a bad > project, but you still have the same hazard of whether you can deliver > useful hints. I agree. > > ... in the processing of the command. The problem is different because it > > occurs in functions that can be called from quite different contexts, and > > the context is not really known to the function. Thus when the error > > occurs in the function, it cannot provide a useful context. As none is > > provided, the user must guess... > > I am not understanding what you have against the existing error context > stack mechanism. Certainly it could be used in more places than it is, > but why do you feel a need to build a separate one? What I understand of the error stack is that it is for error message recursion. 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. Tell me if I'm wrong. If I'm wrong, it means that the infractructure is already in place, and one just need to put some more context calls. 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. -> processing create table "hello" -> processing constraint $1: CHECK (ind>0) <- -> processing constraint foo: xxx REFERENCES "bye" <- -> processing constraint bla: data NOT NULL <- <- Have a nice day, -- Fabien Coelho - [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
