georg, don't SELECT also sends metadata and then an error in case of error, what is wrong here?

sanja No, for e.g. COM_QUERY cllient expects error packet (0xFF) or metadata. Biut not 0xFF after sending metadata. See https://mariadb.com/kb/en/com_query/

georg SELECT can send not only metadata but also data (part of a result set) and then send an error packet.

and INSERT ... RETURNING returns data as SELECT does.

sanja Can you give me an example where SELECT returns metadata followed by an error?
In the example above the statement failed, so I expect an error (and that is how mysql_real_query was designed), but not any metadata.

georg
Example a sub query that returns more than one row.
For example:

create table t1 (a int);

insert into t1 values (1),(2),(3);

select a from t1 where a=(select a from t1 where a>1);

We first send metadata. Then when we start sending data. And when the sub query shouldn't send more than one row, we get error.
INSERT...RETURNING sends data just like SELECT does

Both the Maria and the MySQL documentation describe the return value of the mysql_real_query function:
"Zero for success. Nonzero if an error occurred. "

The current implementation breaks the API but is also not consistent:

create table t1 (a int primary key);

create table t2 (a int);

insert into t1 values (1),(2),(3);

insert into t2 values select a from t1;

/* this will return an error */

rc= mysql_real_query(mysql, SL("SELECT a FROM t1 WERE a= (SELECT a FROM t1))");

/* this wil lnot return an error */

rc= mysql_real_query(mysql, SL("SELECT a FROM t2 WHERE a=(SELECT a FROM t2))");

Also the documentation for mysql_field_count states, that this function should be used to determine if a previously exceuted statement produced a result set. In Connectors we use this to allocate buffers before processing the resultset. It doesn't make sense to allocate buffers for processing result set if an error instead of a result set will follow.

The current implementation is not only inconsistent, it also breaks a lot of applications.

PQExec (postgresql client library) for example returns an error immediately with and without index.

I will reopen this ticket - if it is not a server bug, it should be changed to documentation issue, since it needs to be documented when and under which circumstances mysql_send_query, mysql_real_query and mysql_stmt_execute will not return an error and how to handle errors with unbuffered result sets and server side cursors. Also the client/server protocol documentation needs to be updated.

georg Yes exactly what I meant, sending error after metadata is not a server bug, it always can do so.

georg you better create clear MDEV for documentation with reference to this bug, otherwise docuentation team will have hard time to understand what is needed from them.