Thread: Error messages --- now that we've got it, do you like it?
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
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 oflog_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, Pennsylvania19073
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, Pennsylvania19073
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, Pennsylvania19073
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, Pennsylvania19073
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)