Is there a reason this row number cannot be a part of the error message itself (in addition to diagnostics property)?
It wouldn't be anything new, we already have it for some errors, e.g.
ERROR 1406 (22001): Data too long forcolumn'c'at row 2
While diagnostics property is useful to detect the number of the flawed row programmatically, in interactive execution having it in the error text is clearly more user-friendly, especially when many values are involved:
Discussed on slack with serg that ERROR_INDEX could most probably work for other statements but not sure which error messages can be used safely because there are some error messages that are not unique to statements.
Rucha Deodhar
added a comment - - edited Discussed on slack with serg that ERROR_INDEX could most probably work for other statements but not sure which error messages can be used safely because there are some error messages that are not unique to statements.
I'm not sure what "not unique to statements" in this context means, but anyway, indeed there are certainly error messages universal enough so that a row number doesn't make sense in all (or even most) cases. Here is one example, it's rather artificial, which is in itself proves the point.
MariaDB [test]> createtable t1 (a int);
Query OK, 0 rows affected (0.026 sec)
MariaDB [test]> createtrigger tr afterinserton t1 for each row select * into outfile 'f1'from t1;
Query OK, 0 rows affected (0.017 sec)
MariaDB [test]> insertinto t1 values (1),(2);
ERROR 1086 (HY000): File 'f1' already exists
MariaDB [test]> get diagnostics condition 1 @n=error_index; select @n;
Query OK, 0 rows affected (0.001 sec)
+------+
| @n |
+------+
| 2 |
+------+
1 row inset (0.000 sec)
So, while for this specific weird usage a row number does make sense and extending the message to File 'f1' already exists for row 2 would look all right, of course in the majority of cases ER_FILE_EXISTS_ERROR happens on a higher level and row numbers are meaningless there.
I guess choosing which error messages can be extended with row numbers requires some tedious research of how the messages are used. In my opinion it's still worth doing, but probably it's well outside the scope of MDEV-10075, so it's okay with me if you close it or detach it from 10.7 preview activities.
Elena Stepanova
added a comment - I'm not sure what "not unique to statements" in this context means, but anyway, indeed there are certainly error messages universal enough so that a row number doesn't make sense in all (or even most) cases. Here is one example, it's rather artificial, which is in itself proves the point.
MariaDB [test]> create table t1 (a int );
Query OK, 0 rows affected (0.026 sec)
MariaDB [test]> create trigger tr after insert on t1 for each row select * into outfile 'f1' from t1;
Query OK, 0 rows affected (0.017 sec)
MariaDB [test]> insert into t1 values (1),(2);
ERROR 1086 (HY000): File 'f1' already exists
MariaDB [test]> get diagnostics condition 1 @n=error_index; select @n;
Query OK, 0 rows affected (0.001 sec)
+ ------+
| @n |
+ ------+
| 2 |
+ ------+
1 row in set (0.000 sec)
So, while for this specific weird usage a row number does make sense and extending the message to File 'f1' already exists for row 2 would look all right, of course in the majority of cases ER_FILE_EXISTS_ERROR happens on a higher level and row numbers are meaningless there.
I guess choosing which error messages can be extended with row numbers requires some tedious research of how the messages are used. In my opinion it's still worth doing, but probably it's well outside the scope of MDEV-10075 , so it's okay with me if you close it or detach it from 10.7 preview activities.
elenst , I meant some error messages are used for more than one statements, example "data truncated for col 'a' row i" is used for alter, update and insert and some of them are not universal enough.
Rucha Deodhar
added a comment - elenst , I meant some error messages are used for more than one statements, example "data truncated for col 'a' row i" is used for alter, update and insert and some of them are not universal enough.
ERROR 22007: Illegal double'1.79769313486232e+308' value found during parsing
while ERROR_INDEX is 2 here, the error about "invalid double" can happen anywhere, and in many cases the concept of "current row" won't be applicable.
Sergei Golubchik
added a comment - An example of "not unique to statements" is this error from the test case:
INSERT INTO t1 VALUES (5, 'e' ,1.00105),(6, 'f' ,1.79769313486232e+308);
ERROR 22007: Illegal double '1.79769313486232e+308' value found during parsing
while ERROR_INDEX is 2 here, the error about "invalid double" can happen anywhere, and in many cases the concept of "current row" won't be applicable.
Right, got it. Same as in my example with ER_FILE_EXISTS_ERROR, then.
I just had read "not unique to statements" in a completely different way (as "used not only for statements, but also for something else"), and it was confusing.
Elena Stepanova
added a comment - Right, got it. Same as in my example with ER_FILE_EXISTS_ERROR, then.
I just had read "not unique to statements" in a completely different way (as "used not only for statements, but also for something else"), and it was confusing.
Bug
Critical
MDEV-10075 Provide index of error causing error in array INSERT
Discussed on slack with serg that ERROR_INDEX could most probably work for other statements but not sure which error messages can be used safely because there are some error messages that are not unique to statements.