Use diag_set() to describe VDBE errors in SQL. #4074

ImeevMA · 2019-03-23T13:07:52Z

Currently there are two ways to describe errors in SQL - diag_set() and sqlVdbeError(). This leads to incorrect error descriptions due to possible changes in the error code. It also complicates the work with errors.

This issue continues issues #3965 and #3036.

The module legacy.c is not used and should be removed. Needed for #4074

Thise macros unused and should be removed. Needed for #4074

These functions unused and should be removed. Needed for #4074

Errors SQL_TARANTOOL_DELETE_FAIL, SQL_TARANTOOL_ITERATOR_FAIL and SQL_TARANTOOL_INSERT_FAIL have almost no functionality, but can lead to incorrect behavior. This patch replaces them with SQL_TARANTOOL_ERROR. Part of #4074

Currently, the mayAbort field is used only in one place in debug mode and is not used in non-debug mode. This patch removes this field. Part of #4074

Before this patch it was possible to have an error code with wrong error description. This patch fixes it. Part of #4074

After this patch, the only error code that the OP_Halt opcode will work with is SQL_TARANTOOL_ERROR. Part of #4074

Currently, the mayAbort field is used only in one place in debug mode and is not used in non-debug mode. This patch removes this field. Part of #4074

Before this patch it was possible to have an error code with wrong error description. This patch fixes it. Part of #4074

After this patch, the only error code that the OP_Halt opcode will work with is SQL_TARANTOOL_ERROR. Part of #4074

This patch removes part of unused functions and macros from main.c. This will facilitate the work of removing SQL error/status codes. Needed for #4074

Currently, in OP_Halt, you can get a SQL error other than SQL_TARANTOOL_ERROR, for example, the SQL_CONSTRAINT error. After this patch, all errors going through OP_Halt will have SQL error code SQL_TARANTOOL_ERROR and have diag set. Part of #4074

Since the interrupt system is no longer used in SQL, the SQL_INTERRUPT error is out of date and should be removed. Also this patch removes currently unused progress callback system. Part of #4074

This patch replaces SQL error SQL_MISMATCH by Tarantool error ER_SQL_TYPE_MISMATCH. Part of #4074

After this patch, all errors in VDBE will be set using diag_set(). Part of #4074

This field become unused and should be removed. Part of #4074

Currently, in OP_Halt, you can get a SQL error other than SQL_TARANTOOL_ERROR, for example, the SQL_CONSTRAINT error. After this patch, all errors going through OP_Halt will have SQL error code SQL_TARANTOOL_ERROR and have diag set. Part of #4074

After this patch, all errors in VDBE will be set using diag_set(). Part of #4074

After this patch, all errors in the SQL functions will be set using diag_set(). Closes #4074

Currently, in OP_Halt, you can get a SQL error other than SQL_TARANTOOL_ERROR, for example, the SQL_CONSTRAINT error. After this patch, all errors going through OP_Halt will have SQL error code SQL_TARANTOOL_ERROR and have diag set. Part of #4074

After this patch, all errors in VDBE will be set using diag_set(). Part of #4074

After this patch, all errors in the SQL functions will be set using diag_set(). Closes #4074

Currently, in OP_Halt, you can get a SQL error other than SQL_TARANTOOL_ERROR, for example, the SQL_CONSTRAINT error. After this patch, all errors going through OP_Halt will have SQL error code SQL_TARANTOOL_ERROR and have diag set. Part of #4074

After this patch, all errors in the SQL functions will be set using diag_set(). Part of #4074

After this patch, all errors in VDBE will be set using diag_set(). Closes #4074

Follow-up for #4074

Totktonada · 2019-05-30T20:18:11Z

I'm a bit late, but it worth to have SQLSTATE errors in a mind when designing the error codes: ODBC and JDBC connectors will need to map tarantool's error codes into SQLSTATE (until we'll support them natively). I found it helpful to have meaningful SQLSTATE codes in a connector, at least because some tools (that are use an ODBC API) show you just code w/o a message when something went wrong. See https://docs.microsoft.com/en-us/sql/odbc/reference/appendixes/appendix-a-odbc-error-codes?view=sql-server-2017 for the list of SQLSTATE codes.

kostja · 2019-05-31T06:11:57Z

diag_set() was designed with sqlstate codes in mind. Just go ahead and augment errcode.h/c with sqlstates. The sqlstate should be chosen by diag_set() automatically, based on the error code, and sent to the client in an extra field. Or you could make sqlstate table an additional piece of metadata available in box.error, so that you can download it on the client and do the mapping on the client. This way you don't even need to change the protocol.

kostja · 2019-05-31T06:12:22Z

sqlstate works is clearly outside the scope of this patch, though.

Totktonada · 2019-05-31T11:19:59Z

Now we support mapping in tarantool-c (in WIP ODBC implementation), this is okay. If we'll decide to add these codes to the protocol in the future it would be convenient for connectors, but of course it is not a blocker and not the scope of this issue.

Don't get the idea about placing sqlstate in box.error w/o touching protocol. It'll not help ODBC/JDBC, because a separate call to catch a last error can show an error from another request. It can help cases when we're able to define a custom function in tarantool.

kostja · 2019-05-31T17:53:34Z

I meant this:

---
- NO_SUCH_FIELD_NAME: 153
  UNKNOWN_REPLICA: 62
  WRONG_INDEX_RECORD: 106
  NO_SUCH_TRIGGER: 34
  SEQUENCE_EXISTS: 146
  CHECKPOINT_IN_PROGRESS: 120
  CONSTRAINT_EXISTS: 170
  FIELD_TYPE: 23
  SQL_BIND_PARAMETER_MAX: 158
  WRONG_SPACE_FORMAT: 141

Today it shows a list of all available errors with all their codes. Tomorrow it could list their SQLSTATES as well, not just the codes.
The client could load this data along with the schema.