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