Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 10.0.6
-
Fix Version/s: 10.0.8
-
Component/s: None
-
Labels:None
-
Environment:windows,linux
Description
For most SQL statements, eg, delete, select etc, if i return a HA_ERRO_GENERIC, then Mariadb/Mysql will call back into the storage engine via the following function.
handler::print_error(int error, myf errflag) { .... default: { /* The error was "unknown" to this function. Ask handler if it has got a message for this error */ bool temporary= FALSE; String str; temporary= get_error_message(error, &str); ... }
Which will then call into the storage engine function
virtual bool get_error_message(int error, String *buf);
I am then able to return my custom error message.
However, If a CREATE TABLE fails, and i return a HA_ERR_GENERIC mariadb never call back into the storage engine to get the custom error, so my custom error will not get shown. Instead an ambiguous error like this will get returned.
ERROR 1005 (HY000): Can't create table `test`.`call_data_record31` (errno: 168 "Unknown (generic) error from engine")
Is this a know problem, or is there something i need to do to get generic errors returned when a create table fails.
note even if i enable --show-warnings, i am still not getting the custom errors back when create table fails.
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Yes, returning the custom error information as a warning will be OK (ie. via SHOW WARNINGS)
thanks,
michael.
I cannot really use get_error_message() instead of the current error message. The current message says "Can't create table..." and the error number. Calling handler::print_error() instead would've replaced that with "Got error NNN from..." which is not appropriate here, particularly if the engine doesn't provide a custom error message for this case.
But I can call handler::print_error() in addition to the "Can't create table..." error message. Custom engine error text will be visible in SHOW WARNINGS (or, exactly, with --show-warnings). Would that be ok for you?