MySQL Bugs: #90304: Prepared statements with cursor truncate microseconds

Bug #90304	Prepared statements with cursor truncate microseconds
Submitted:	4 Apr 2018 14:11	Modified:	4 May 2018 14:55
Reporter:	Aaron Stone	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: Prepared statements	Severity:	S3 (Non-critical)
Version:	5.6.33	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
Code example presented in Ruby because I am the maintainer of the mysql2 Ruby binding to Connector/C. Also reproduceable in C.

https://github.com/brianmario/mysql2/pull/958#issuecomment-378609533

I have found that adding a CURSOR to mysql_stmt_execute() results in loss of microseconds from prepared statement results.

    unsigned long type = CURSOR_TYPE_READ_ONLY;
    mysql_stmt_attr_set(stmt_wrapper->stmt, STMT_ATTR_CURSOR_TYPE, &type);

Possibly related to #86818 ?

How to repeat:
  it "should prepare DateTime values with microseconds" do
    now = DateTime.now
    statement = @client.prepare('SELECT ? AS a')
    result = statement.execute(now)
    # microseconds is six digits after the decimal, but only test on 5 significant figures
    expect(result.first['a'].strftime('%F %T.%5N %z')).to eql(now.strftime('%F %T.%5N %z'))
  end

With cursor:

       expected: "2018-04-04 06:54:50.60401 -0700"
            got: "2018-04-04 06:54:51.00000 -0700"

(microseconds are truncated)

Without cursor:

       expected: "2018-04-04 06:54:50.60401 -0700"
            got: "2018-04-04 06:54:50.60401 -0700"

(values match)

Possibly related to https://bugs.mysql.com/bug.php?id=86818

Repro with MySQL 5.7.17 on Mac OS, and MySQL 5.6.33 on Linux.

Thank you for the bug report. Please provide the complete test case with C. Thanks.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".