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
mascarm@mascari.com