Bug #47485 mysql_store result returns a result set for a prepared statement
Submitted: 21 Sep 2009 15:14 Modified: 8 Oct 2010 14:35
Reporter: Ulf Wendel Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: C API (client library) Severity:S3 (Non-critical)
Version:5.1 OS:Any
Assigned to: Dmitry Shulga CPU Architecture:Any
Triage: Triaged: D3 (Medium)

[21 Sep 2009 15:14] Ulf Wendel
Description:
mysql_store results returns a result set for a prepared statement. 

As I understand http://dev.mysql.com/doc/refman/5.1/en/mysql-store-result.html it should return NULL for prepared statements. 

(Related: PHP users asking for PS result set to be returned at http://bugs.php.net/bug.php?id=45289)

How to repeat:
See attached C test program
[21 Sep 2009 15:14] Ulf Wendel
Test program

Attachment: statement_store.c (text/x-csrc), 2.20 KiB.

[21 Sep 2009 19:52] Sveta Smirnova
Thank you for the report.

Verified as described.
[21 Jul 2010 8:32] Konstantin Osipov
An attempt to do mysql_store_result() or mysql_use_result() after mysql_stmt_execute() should lead to "Сommands out of sync" error. Dmitry, please implement this and pass it on to Paul to document in the manual.
[27 Jul 2010 8:53] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/114411

3456 Dmitry Shulga	2010-07-27
      Fixed bug #47485 - mysql_store_result returns a not NULL result set for a prepared statement.
     @ include/mysql.h
        enumerator MYSQL_STATUS_STATEMENT_GET_RESULT was added into mysql_status enum.
     @ include/mysql.h.pp
        enumerator MYSQL_STATUS_STATEMENT_GET_RESULT was added into mysql_status enum.
     @ libmysql/libmysql.c
        Introduce a separate mysql state to distinguish the situation
        when we have a binary result set pending on the server from the
        situation when the result set is in text protocol.
        execute() modified: set mysql->status= MYSQL_STATUS_STATEMENT_GET_RESULT
        before return. stmt_read_row_unbuffered() and mysql_stmt_store_result()
        were modified: added checking for mysql->status against
        MYSQL_STATUS_STATEMENT_GET_RESULT value instead of MYSQL_STATUS_GET_RESULT.
[29 Jul 2010 11:00] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/114624

3456 Dmitry Shulga	2010-07-29
      Fixed bug #47485 - mysql_store_result returns a not NULL result set for a prepared statement.
     @ include/mysql.h
        enumerator MYSQL_STATUS_STATEMENT_GET_RESULT was added into mysql_status enum.
     @ include/mysql.h.pp
        enumerator MYSQL_STATUS_STATEMENT_GET_RESULT was added into mysql_status enum.
     @ libmysql/libmysql.c
        Introduce a separate mysql state to distinguish the situation
        when we have a binary result set pending on the server from the
        situation when the result set is in text protocol.
        execute() modified: if mysql->status == MYSQL_STATUS_GET_RESULT
        before return then set it to value MYSQL_STATUS_STATEMENT_GET_RESULT.
        stmt_read_row_unbuffered() and mysql_stmt_store_result()
        were modified: added checking for mysql->status against
        MYSQL_STATUS_STATEMENT_GET_RESULT value instead of MYSQL_STATUS_GET_RESULT.
     @ tests/mysql_client_test.c
        added test_bug47485()
[7 Sep 2010 7:20] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/117667

3499 Dmitry Shulga	2010-09-07
      Fixed bug #47485 - mysql_store_result returns a not NULL result set
      for a prepared statement.
     @ include/mysql.h
        enumerator MYSQL_STATUS_STATEMENT_GET_RESULT was added
        into mysql_status enum.
     @ include/mysql.h.pp
        enumerator MYSQL_STATUS_STATEMENT_GET_RESULT was added
        into mysql_status enum.
     @ libmysql/libmysql.c
        Introduce a separate mysql state to distinguish the situation
        when we have a binary result set pending on the server from the
        situation when the result set is in text protocol.
        execute() modified: if mysql->status == MYSQL_STATUS_GET_RESULT
        before return then set it to value MYSQL_STATUS_STATEMENT_GET_RESULT.
        stmt_read_row_unbuffered() and mysql_stmt_store_result()
        were modified: added checking for mysql->status against
        MYSQL_STATUS_STATEMENT_GET_RESULT value instead of MYSQL_STATUS_GET_RESULT.
     @ tests/mysql_client_test.c
        added test_bug47485()
[8 Sep 2010 10:27] Bjørn Munch
It looks like this fix is causing mysql_client_test to fail in the subtest test_wl4435 (not the one that was added). From my run:

---
#####################################
225 of (1/1): test_wl4435  
#####################################

exec_counter: 0
num_fields: 4
  - 0: name: 'a1'/'a1'; table: 't1'/'t1'; db: 'client_test_db'; catalog: 'def'; length: 11; max_length: 0; type: 3; decimals: 0
  - 1: name: 'a2'/'a2'; table: 't1'/'t1'; db: 'client_test_db'; catalog: 'def'; length: 32; max_length: 0; type: 254; decimals: 0
  - 2: name: 'a3'/'a3'; table: 't1'/'t1'; db: 'client_test_db'; catalog: 'def'; length: 4; max_length: 0; type: 5; decimals: 2
  - 3: name: 'a4'/'a4'; table: 't1'/'t1'; db: 'client_test_db'; catalog: 'def'; length: 5; max_length: 0; type: 246; decimals: 1
Data:
  int: 1; str: '11'; dbl: 12.340000; dec: '56.7';
  int: 2; str: '12'; dbl: 56.780000; dec: '90.1';
  int: 3; str: '13'; dbl: 23.450000; dec: '67.8';
EOF
mysql_stmt_next_result(): 0; field_count: 5
num_fields: 5
  - 0: name: 'b0'/'b0'; table: 't2'/'t2'; db: 'client_test_db'; catalog: 'def'; length: 11; max_length: 0; type: 3; decimals: 0
  - 1: name: 'b1'/'b1'; table: 't2'/'t2'; db: 'client_test_db'; catalog: 'def'; length: 11; max_length: 0; type: 3; decimals: 0
  - 2: name: 'b2'/'b2'; table: 't2'/'t2'; db: 'client_test_db'; catalog: 'def'; length: 32; max_length: 0; type: 254; decimals: 0
  - 3: name: 'b3'/'b3'; table: 't2'/'t2'; db: 'client_test_db'; catalog: 'def'; length: 4; max_length: 0; type: 5; decimals: 2
  - 4: name: 'b4'/'b4'; table: 't2'/'t2'; db: 'client_test_db'; catalog: 'def'; length: 5; max_length: 0; type: 246; decimals: 1
Data:
EOF
mysql_stmt_next_result(): 2014; field_count: 5
Error: Commands out of sync; you can't run this command now (errno: 2014)
/home/bm136801/my/merge-nx/tests/mysql_client_test.c:1934: check failed: 'rc > 0'
----

Line 1934 is here in my sandbox:

      if (rc > 0)
      {
        printf("Error: %s (errno: %d)\n",
               mysql_stmt_error(stmt), mysql_stmt_errno(stmt));
>>>        DIE(rc > 0);
      }

See also PB2 for mysql-5.5-merge.
[9 Sep 2010 12:36] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/117858

3196 Dmitry Shulga	2010-09-09
      Fix mysql_client_test failure introduced by a patch for Bug#47485.
      The problem was that mysql_stmt_next_result() (new to 5.5)
      was not properly updated.
     @ libmysql/libmysql.c
        mysql_stmt_next_result() modified: set mysql->status= MYSQL_STATUS_STATEMENT_GET_RESULT before return
        if there is a result set.
[9 Sep 2010 12:38] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/117860

3197 Dmitry Shulga	2010-09-09
      Fix mysql_client_test failure introduced by a patch for Bug#47485.
      The problem was that mysql_stmt_next_result() (new to 5.5)
      was not properly updated.
     @ libmysql/libmysql.c
        mysql_stmt_next_result() modified: set mysql->status= MYSQL_STATUS_STATEMENT_GET_RESULT before return
        if there is a result set.
[9 Sep 2010 13:21] Ulf Wendel
How are libmysql and C/C sources keept in sync: will this be fixed in C/C as well, assuming it also affects C/C?
[10 Sep 2010 9:05] Dmitry Shulga
Pushed to mysql-5.1-bugteam. Merged and pushed to mysql-5.5-merge.
[28 Sep 2010 15:38] Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@sun.com-20100928153607-tdsxkdm5cmuym5sq) (version source revid:alik@sun.com-20100928153508-0saa6v93dinqx1u7) (merge vers: 5.6.1-m4) (pib:21)
[28 Sep 2010 15:41] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100928153646-pqp8o1a92mxtuj3h) (version source revid:alik@sun.com-20100928153532-lr3gtvnyp2en4y75) (pib:21)
[28 Sep 2010 15:43] Bugs System
Pushed into mysql-5.5 5.5.7-rc (revid:alik@sun.com-20100928153459-4nudf4zgzlou4s7q) (version source revid:alik@sun.com-20100928153459-4nudf4zgzlou4s7q) (merge vers: 5.5.7-rc) (pib:21)
[4 Oct 2010 15:10] Paul Dubois
Noted in 5.5.7, 5.6.1 changelogs.

mysql_store_result() and mysql_use_result() are not for use with
prepared statements and are not intended to be called following
mysql_stmt_execute(), but failed to return an error when invoked that 
way.    

Also updated mysql_stmt_execute() section.

Setting report to Need Merge pending push to 5.1.x.
[8 Oct 2010 14:35] Paul Dubois
Noted in 5.1.52 changelog.
[1 Nov 2010 19:00] Bugs System
Pushed into mysql-5.1 5.1.53 (revid:build@mysql.com-20101101184443-o2olipi8vkaxzsqk) (version source revid:build@mysql.com-20101101184443-o2olipi8vkaxzsqk) (merge vers: 5.1.53) (pib:21)