"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> ... I would have thought 'terse' would include the error number. Even
> _just_ the error number.
Well, we can talk about that, but remember this is psql's take on what
to display, not anyone else's. IMHO it should be designed for human
readability --- programs aren't going to be looking at its output,
only people. Error codes are being added for the use of programs, and
programs will have other APIs that they use to get at 'em.
In my mind, making people look at error codes in place of readable
messages went out with the punch card.
> I presume this setting is completely different from the one to determine the
> verbosity in the server log.
Right, this is psql. The current code offers exactly the same three
verboseness levels for server log entries, but there's no hard and fast
reason for them to be the same.
> In the server logs I would think it better to be
> able to include the error code in the error line without having any other
> detail lines.
I think you vastly overestimate the usefulness of the bare error code.
We are *not* planning to make one error code per distinct error message;
for example, there'll be one code for "undefined function or operator"
regardless of the context the problem occurs in. I'm not even really
convinced that I should have bothered with separate error codes for the
two examples I gave (unknown versus non-unique operator). Really the
error codes are designed to let programs have some idea of whether they
can recover from a failure --- for example, that's why SQL99 doesn't
have a problem with lumping every variety of syntax error under one
code, because it's unlikely a program will be able to repair a syntax
error in a query it's issued. AFAICS people will always want to look
at the primary error message.
However, I wouldn't object to redesigning the log verbosity mechanism
so that my ideas about this aren't imposed on other people. Maybe allow
settings along the line of
log_error_fields = 'code,message,details'
where you pick out the fields you want?
> In fact in the server log would it not be the case that the
> LOCATION detail came before the HINT detail in the verbosity stakes, or is it
> viewed as being closer to a debug setting and so requires more verbosity?
In most cases LOCATION should be effectively a debug detail. We'd ask
for it in bug reports but I can't imagine non-developers having much use
for it otherwise. CONTEXT, which is the user-land aspect of location,
that is the user function call stack, *is* included in the default set
of fields to display. I didn't give an example of it, but here's one:
regression=# create function fooey(real) returns real as '
regression'# begin
regression'# return 1.0 / $1;
regression'# end' language plpgsql;
CREATE FUNCTION
regression=# select fooey(0);
ERROR: division by zero
CONTEXT: PL/pgSQL function fooey line 2 at return
The verbose version of this adds "LOCATION: float84div, float.c:1840"
but I can't see that being wanted in the default field set.
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
