Bruce Momjian wrote: > > > (switched thread to hackers) > > > > > ... If the 'tip' is localized to a few lines, usually in > > > gram.y, I don't see a reason not to help people find the right answer. > > > It helps them and reduces redundant bug repots. I can't imagine a > > > reason not to do it unless it starts to make our code more complex. > > > > I'm with Peter on this one. I'd like to *not* clutter up the code and > > error reporting with hints and suggestions which may or may not be to > > the point. > > > > We *should* have docs which list error messages and possible solutions, > > and throwing that info into code is a poor second choice imho. > > Is it really clutter to add a clause and elog(). I am not advocating > adding stuff like crazy, but when we see people having the same problem, > it seems worth adding it. Our docs are pretty big and most people who > have this type of problem are not going to know where to look in the > docs. If the elog pointed them to the proper section in the docs, that > would be even better, but then again, you are doing the elog at that > point. > > What do others think? It would be good to have a specific example to > discuss.
FWIW, Oracle has its "oerr" utility which takes the arguments: oerr facility error-code So the RDBMS generates an error code with a single line message less than or equal to 76 characters in length, prefixed by the facility and error code: ORA-01034: ORACLE not available The user can then get detailed information through the oerr utility. It would be nice, when we have error codes (are they apart of the new NLS support?), we have a "pgerr" utility to serve the same purpose. And of course the message files shipped with Oracle contain localized messages. Example output: $oerr ora 12203 12203, 00000, "TNS:unable to connect to destination" // *Cause: Invalid TNS address supplied or destination is not listening. // This error can also occur because of underlying network transport // problems. // *Action: Verify that the service name you entered on the command line // was correct. Ensure that the listener is running at the remote node and // that the ADDRESS parameters specified in TNSNAMES.ORA are correct. // Finally, check that all Interchanges needed to make the connection are // up and running. It would then be nice to have both a command-line version of the PostgreSQL equivalent and a web-based version on postgresql.org for users to use. Just my 2 cents, of course, Mike Mascari [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
