Fabien COELHO <[EMAIL PROTECTED]> writes: > (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. In particular, we determined that the appropriate place for this sort of thing is on the client side, not in the backend. Only the client knows what is a reasonable way to mark the error position. (Think about GUI clients vs command line clients, different size windows, etc.) As of 7.4 we do send back a cursor offset as one of the fields of an error message, and I think the next step is to make the client-side code do something with that. > All generated error messages, especially from the parser, should be > assorted with a HINT to help the user, if possible. Something like: > HINT: table name expected 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. I don't think your idea of relying on the last parser state will work well, because the parser frequently is off a word or two as to the actual location of the error (since it will do its best to make sense of what it sees, until there is no remaining possibility of a successful parse). That will be enough to cause you to deliver the wrong hint, and a wrong hint is worse than none. 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. > ... 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? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly