WL#3417: Error Messages Prefix

From Jonathan Miller

The sample output below show several different error number types. We have NDB
errors, MySQL errors and SQL State errors. After a user has been working with
MySQL for a while they might begin to be able to tell which error is from what
part, but not until you have had to fight with it for a while.

You have:
* Error_code
* Got error
* errno
* server_errno

I don't find this to be user friendly or even well documented. And with new
storage engine coming I can only see if getting worse.

Suggestion Short Term:

My Short term suggestion is that we document what is what. i.e. Error_code = SQL
State and errno = mysql, etc...

Suggestion Long Term:

That we open a work log and change the numbering to include a prefix i.e.

MySQL_ERROR: ####
NDB_ERROR: ####
SQLSTATE_ERROR: ####
FALCON_ERROR: ####
Etc,


From Roland Bouman, Certification Developer

I can confirm that Oracle adheres to such a system. Some prefixes:

TNS: network protocol related problems
PLS: problems in the stored procedure (PL/SQL) extension engine (that's because
they have several execution environments for PL/SQL)
ORA: Oracle server error messages. could be ordinary SQL errors, or physical
problems such as resource shortages.

From Hartmut on IRC

hartmut|around	jeb: you only forgot to mention all those "internal server
errors" >1000 we expose to the client side all the time ... without resolving
them with perror

From Kaj

Concur 100 % that this needs to be cleaned up!

I would welcome it if you wrote up a suggested worklog item, and then got it
approved by Trudy & Brian.


Replication Requirements
--------------------------------------------------------------
The binary log contains the error code of each executed 
statement (O if no error).  The slave needs to mimic this 
error code to allow replication to continue.  So:

1. All error codes resulting from statement execution
   needs to be loggable in the binary log.  (In 5.1 and below 
   the error code is coded as 2 bytes in query_log_event.
   Changing this to e.g. 4 bytes means either creating a 
   new query_log_event log event type or increasing the 
   binlog version number.)

2. There needs to be an easy way to interpret the error code
   stored in the binary log to see why a statement failed 
   on master but succeeded on slave (or the opposite).

(The above are very simple requirements to satisfy.  
They are just listed here so that they are not forgotten.)

Note added by Trudy Pelzer, 2006-08-28
During a discussion between Brian Aker, Calvin Sun, Elliot
Murphy and me today, the decision was made that it's too
late to do this work for MySQL 5.1.
-- end note

Client-server protocol note:
-------------------------------
Instead of encoding the source of an error in the error message text, we should
add a separate field in
the client-server protocol for the source. This is one of many attributes of an
error, and
we already treat errors as composite objects, containing error code, error
message, sqlstate.
See also BUG#17034 "Error messages from stored routines should name their source".