Repository navigation
Conversation
|
This does not sound right. At first sight, I think the return value was ignored here on purpose, but I will try to look into this more. Either way, this is not a bug fix so it should go on master. |
pdo_stmt_do_next_rowset() dropped the return value of pdo_stmt_describe_columns(), so a driver whose describer failed after the rowset advance left columns[] partially initialized while nextRowset() still reported success, and the next fetch read that incomplete state. Check the result, as pdo_stmt_do_execute(), do_fetch() and PDO::query() already do, and release the partial columns so a fetch after the failure cannot read them.
5cccffb to
3d31c58
Compare
|
You're right. pdo_mysql's describer returns 0 on the empty result set that ends a CALL, so this check turns that nextRowset() into a failure: pdo_mysql_stmt_nextrowset.phpt, pdo_mysql_multi_stmt_nextrowset.phpt, bug_39858.phpt and pdo_mysql_attr_oracle_nulls.phpt all fail with it. Closing. |
I wouldn't be so quick. I believe the test failures are unrelated. It seems that mysqlnd didn't act according to the standard and didn't clear the field_count on next_result, which is why the PDO code failed. See my new PR. I haven't decided yet whether what you are proposing is correct or not. |
|
My final judgement: let's not add this check. Let's follow up with the mysqlnd fix only. I cannot find a way in which this check would make any difference. |
pdo_stmt_do_next_rowset() dropped the return value of pdo_stmt_describe_columns(), so a driver whose describer failed after the rowset advance left columns[] partially initialized while nextRowset() still reported success, and the next fetch read that incomplete state. pdo_stmt_do_execute(), do_fetch() and PDO::prepare() already check it. No test: odbc_stmt_describe() fails when SQLDescribeCol() or SQLColAttribute() does, which needs a server driven into that state, and the bundled sqlite describer only fails for a column index past its own count, which the describe loop never passes it.