Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-683

LP:737442 - mysql_stmt_store_result() does not work after an unsuccessfull call to mysql_stmt_bind_result()

    Details

    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 10.0.1, 5.5.30, 5.1.67, 5.2.14, 5.3.12
    • Fix Version/s: None
    • Component/s: None

      Description

      A mysql_stmt_bind_result() call that results in an error prevents future mysql_stmt_store_result() from working since stmt->lasterrno is now set.

      Example:

      int test_store_result_1(MYSQL *mysql)
      {
        MYSQL *stmt;
        int rc;
        char *query= "SELECT 'foo' FROM DUAL";
      
        stmt = mysql_stmt_init(mysql);
        FAIL_IF(!stmt, "stmt_init failed");
      
        rc= mysql_stmt_prepare(stmt, query, strlen(query));
        FAIL_IF(rc, mysql_stmt_error(stmt));
      
        rc= mysql_stmt_execute(stmt);
        FAIL_IF(rc, mysql_stmt_error(stmt));
      
        /* here we store the result set without binding, bind variables
           are required for fetch only */
        rc= mysql_stmt_store_result(stmt);   /* <------- this works ok */
        FAIL_IF(rc, mysql_stmt_error(stmt));
      
        mysql_stmt_close(stmt);
      }
      
      int test_store_result_2(MYSQL *mysql)
      {
        MYSQL *stmt;
        MYSQL_BIND bind[1];
        int rc;
        char *query= "SELECT 'foo' FROM DUAL";
      
        stmt = mysql_stmt_init(mysql);
        FAIL_IF(!stmt, "stmt_init failed");
      
        rc= mysql_stmt_prepare(stmt, query, strlen(query));
        FAIL_IF(rc, mysql_stmt_error(stmt));
      
        rc= mysql_stmt_execute(stmt);
        FAIL_IF(rc, mysql_stmt_error(stmt));
      
        /* Geometry is not supported, mysql_bind_result should fail */
        memset(bind, 0, sizeof(bind));
        bind[0].buffer_type= MYSQL_TYPE_GEOMETRY;
      
        rc= mysql_stmt_bind_result(stmt, bind);
        FAIL_IF(!rc, "Expected error (unsupported buffer type)");
      
        /* We didn't bind as in test_store_result_1, but stmt_store_result
           fails, since it checks for stmt->lasterrno */
        rc= mysql_stmt_store_result(stmt);  /* <-----  this doesn't work */
        FAIL_IF(rc, mysql_stmt_error(stmt));
      
        mysql_stmt_close(stmt);
      }
      

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            ratzpo Rasmus Johansson added a comment -

            Launchpad bug id: 737442

            Show
            ratzpo Rasmus Johansson added a comment - Launchpad bug id: 737442
            Hide
            elenst Elena Stepanova added a comment -

            Reproducible everywhere, but as Georg discovered, this behavior is explicitly covered by test_pure_coverage. so maybe it's intended. It would be interesting to find out why, and, more importantly, how an application is supposed to deal with a "broken" statement handle.

            Assigning to Georg since he's looking into it. If it turns out to be not a bug, it should be closed as such.

            Show
            elenst Elena Stepanova added a comment - Reproducible everywhere, but as Georg discovered, this behavior is explicitly covered by test_pure_coverage. so maybe it's intended. It would be interesting to find out why, and, more importantly, how an application is supposed to deal with a "broken" statement handle. Assigning to Georg since he's looking into it. If it turns out to be not a bug, it should be closed as such.
            Hide
            georg Georg Richter added a comment -

            The current error handling for the prepared statements is kind of suboptimal:

            The pure_coverage test was introduced when more server side cursor types were supported (these options are disabled since 5.1). The test case from Philip shows a "dead end road", since there is no way to reset an error without resetting the statement handle.

            I can see two possible solutions:

            1) Dirty: check the error number in mysql_stmt_store_result and continue

            2) Allow to unbind a result set by specifying a NULL parameter in mysql_stmt_bind_result.

            Show
            georg Georg Richter added a comment - The current error handling for the prepared statements is kind of suboptimal: The pure_coverage test was introduced when more server side cursor types were supported (these options are disabled since 5.1). The test case from Philip shows a "dead end road", since there is no way to reset an error without resetting the statement handle. I can see two possible solutions: 1) Dirty: check the error number in mysql_stmt_store_result and continue 2) Allow to unbind a result set by specifying a NULL parameter in mysql_stmt_bind_result.

              People

              • Assignee:
                georg Georg Richter
                Reporter:
                philipstoev Philip Stoev
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: