Error messages --- now that we've got it, do you like it?

Oops, just remembered I was going to look at the new style error codes to
answer one of your emails before. Just not had the time.

On Thu, 3 Jul 2003, Tom Lane wrote:

First fruits of all that work on error message rejiggering ...

regression=# \set VERBOSE terse

regression=# select 1!! ;
ERROR: operator does not exist: integer !!

I can see why 'terse' contains the least amount of information and that
generally it should not therefore contain information not in the next higher
level but I would have thought 'terse' would include the error number. Even
_just_ the error number.

I presume this setting is completely different from the one to determine the
verbosity in the server log. 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. 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?

regression=# \set VERBOSE default

regression=# select 1!! ;
ERROR: operator does not exist: integer !!
HINT: No operator matches the given name and argument type(s). You may need to add explicit typecasts.

regression=# \set VERBOSE verbose

regression=# select 1!! ;
ERROR: 42883: operator does not exist: integer !!
HINT: No operator matches the given name and argument type(s). You may need to add explicit typecasts.
LOCATION: op_error, parse_oper.c:691

regression=# select 'z' && 'q';
ERROR: 42725: operator is not unique: "unknown" && "unknown"
HINT: Unable to choose a best candidate operator. You may need to add explicit typecasts.
LOCATION: op_error, parse_oper.c:684

Before we go too much further, does this look sane to people?
Any adjustments you want to make around the edges?

(BTW, if you're wondering where the 42xxx error codes came from,
I borrowed them from DB2. The SQL99 spec seems happy to lump
all sorts of conditions under 42000 "syntax error or access
violation" ...)

Looks good. Error codes are always handy to have and the extra details are just
the ticket, I especially like the hint.

--
Nigel J. Andrews

"Nigel J. Andrews" <nandrews@investsystems.co.uk> 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

VERBOSE doesn't seem like the right name for the \set parameter. I
consider VERBOSE to be a possible value for error verbosity. Saying
'\set VERBOSE terse' seems like an contradiction.

Should we call it VERBOSITY, or something else? Seems 'error' or 'err'
or 'message' should be in there somewhere too.

Here is a good example of the problem:

regression=# \set VERBOSE verbose
regression=# \set VERBOSE default
regression=# \set VERBOSE terse

That is just confusing. It is the parameter name and a possible value.

How about MESSOUTPUT or ERROUTPUT? Both look ugly, though.

---------------------------------------------------------------------------

Tom Lane wrote:

First fruits of all that work on error message rejiggering ...

regression=# \set VERBOSE terse

regression=# select 1!! ;
ERROR: operator does not exist: integer !!

regression=# \set VERBOSE default

regression=# select 1!! ;
ERROR: operator does not exist: integer !!
HINT: No operator matches the given name and argument type(s). You may need to add explicit typecasts.

regression=# \set VERBOSE verbose

regression=# select 1!! ;
ERROR: 42883: operator does not exist: integer !!
HINT: No operator matches the given name and argument type(s). You may need to add explicit typecasts.
LOCATION: op_error, parse_oper.c:691

regression=# select 'z' && 'q';
ERROR: 42725: operator is not unique: "unknown" && "unknown"
HINT: Unable to choose a best candidate operator. You may need to add explicit typecasts.
LOCATION: op_error, parse_oper.c:684

Before we go too much further, does this look sane to people?
Any adjustments you want to make around the edges?

(BTW, if you're wondering where the 42xxx error codes came from,
I borrowed them from DB2. The SQL99 spec seems happy to lump
all sorts of conditions under 42000 "syntax error or access
violation" ...)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

VERBOSE doesn't seem like the right name for the \set parameter.

VERBOSITY would be okay with me.

How about MESSOUTPUT or ERROUTPUT? Both look ugly, though.

I agree, I don't care for either of those.

Any other thoughts out there?

regards, tom lane

On Sun, 20 Jul 2003, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

VERBOSE doesn't seem like the right name for the \set parameter.

VERBOSITY would be okay with me.

Sounds meaningful. I often want to say 'verbosity level' when talking such
things.

--
Nigel J. Andrews

Bruce Momjian wrote:

VERBOSE doesn't seem like the right name for the \set parameter. I
consider VERBOSE to be a possible value for error verbosity. Saying
'\set VERBOSE terse' seems like an contradiction.

Should we call it VERBOSITY, or something else? Seems 'error' or 'err'
or 'message' should be in there somewhere too.

Here is a good example of the problem:

regression=# \set VERBOSE verbose
regression=# \set VERBOSE default
regression=# \set VERBOSE terse

That is just confusing. It is the parameter name and a possible value.

How about MESSOUTPUT or ERROUTPUT? Both look ugly, though.

OK, if people like VERBOSITY, I wonder if the values should be more like
a tunable parameter, rather than a behavior, meaning VERBOSITY would
have values like off/default/full, or minimum/default/maximum.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tom, you saw this suggestion, right?

---------------------------------------------------------------------------

Bruce Momjian wrote:

Bruce Momjian wrote:

VERBOSE doesn't seem like the right name for the \set parameter. I
consider VERBOSE to be a possible value for error verbosity. Saying
'\set VERBOSE terse' seems like an contradiction.

Should we call it VERBOSITY, or something else? Seems 'error' or 'err'
or 'message' should be in there somewhere too.

Here is a good example of the problem:

regression=# \set VERBOSE verbose
regression=# \set VERBOSE default
regression=# \set VERBOSE terse

That is just confusing. It is the parameter name and a possible value.

How about MESSOUTPUT or ERROUTPUT? Both look ugly, though.

OK, if people like VERBOSITY, I wonder if the values should be more like
a tunable parameter, rather than a behavior, meaning VERBOSITY would
have values like off/default/full, or minimum/default/maximum.

-- 
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 359-1001
+  If your life is a hard drive,     |  13 Roberts Road
+  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom, you saw this suggestion, right?

I didn't hear anyone else agreeing with it ...

regards, tom lane

That's what I thought... just checking.

---------------------------------------------------------------------------

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom, you saw this suggestion, right?

I didn't hear anyone else agreeing with it ...

regards, tom lane

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Wed, Jul 30, 2003 at 10:33:55PM -0400, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom, you saw this suggestion, right?

I didn't hear anyone else agreeing with it ...

Well, if this needs a vote, I'm for something like maximum/default/minimum
rather than the way it currently is. Saying "verbosity verbose" or
"verbosity terse" doesn't feel right, while "verbosity maximum" makes
sense, to me anyway.

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
Thou shalt study thy libraries and strive not to reinvent them without
cause, that thy code may be short and readable and thy days pleasant
and productive. (7th Commandment for C Programmers)

Alvaro Herrera Munoz wrote:

On Wed, Jul 30, 2003 at 10:33:55PM -0400, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom, you saw this suggestion, right?

I didn't hear anyone else agreeing with it ...

Well, if this needs a vote, I'm for something like maximum/default/minimum
rather than the way it currently is. Saying "verbosity verbose" or
"verbosity terse" doesn't feel right, while "verbosity maximum" makes
sense, to me anyway.

That was my feeling. Also, I was concerned that non-native English
speakers might not have heard of 'terse', while max/min or off/full
would be more common.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Alvaro Herrera Munoz wrote:

Well, if this needs a vote, I'm for something like maximum/default/minimum
rather than the way it currently is. Saying "verbosity verbose" or
"verbosity terse" doesn't feel right, while "verbosity maximum" makes
sense, to me anyway.

"max" would work for the verbose mode, since that corresponds to all
available fields. It's quite unclear what "min" is though; the fields
included by "terse" are more of a judgment call (wasn't there someone
asking for only the SQLSTATE?). off/full would have the same problem.

That was my feeling. Also, I was concerned that non-native English
speakers might not have heard of 'terse', while max/min or off/full
would be more common.

Non-native speakers would probably have to consult the man page to
remember the correct spelling of VERBOSITY anyway :-(

regards, tom lane

Bruce Momjian wrote:

That was my feeling. Also, I was concerned that non-native English
speakers might not have heard of 'terse', while max/min or off/full
would be more common.

Possibly plenty of "English" speakers, too ;-)

andrew