mirror of
https://github.com/php/php-src.git
synced 2026-03-24 08:12:21 +01:00
f133f0024e
The fix for feature request #53466 did not properly handle resetting of the corresponding statement; the problem with this is that the statement does not know about its result sets. But even if we could fix this, the `complete` handling still appears to be brittle, since the `sqlite3_column_type()`docs[1] state: | If the SQL statement does not currently point to a valid row, or if | the column index is out of range, the result is undefined. Fortunately, we can use `sqlite3_data_count()` instead, since[2]: | If prepared statement P does not have results ready to return (via | calls to the sqlite3_column() family of interfaces) then | sqlite3_data_count(P) returns 0. Thus, we guard `SQLite3::columnType()` with `sqlite3_data_count()`, and completely drop updating the `php_sqlite3_result_object.complete` field, but keep it for ABI BC purposes. [1] <https://www.sqlite.org/c3ref/column_blob.html> [2] <https://www.sqlite.org/c3ref/data_count.html>
35 lines
772 B
PHP
35 lines
772 B
PHP
--TEST--
|
|
Bug #79294 ()::columnType() may fail after SQLite3Stmt::reset())
|
|
--SKIPIF--
|
|
<?php
|
|
if (!extension_loaded('sqlite3')) die('sqlite3 extension not available');
|
|
?>
|
|
--FILE--
|
|
<?php
|
|
$db = new SQLite3(':memory:');
|
|
$db->exec("CREATE TABLE foo (bar INT)");
|
|
$db->exec("INSERT INTO foo VALUES (1)");
|
|
|
|
$stmt = $db->prepare("SELECT * FROM foo");
|
|
$res = $stmt->execute();
|
|
var_dump($res->fetchArray() !== false);
|
|
var_dump($res->columnType(0));
|
|
var_dump($res->fetchArray() !== false);
|
|
var_dump($res->columnType(0));
|
|
$stmt->reset();
|
|
var_dump($res->fetchArray() !== false);
|
|
var_dump($res->columnType(0));
|
|
$res->reset();
|
|
var_dump($res->fetchArray() !== false);
|
|
var_dump($res->columnType(0));
|
|
?>
|
|
--EXPECT--
|
|
bool(true)
|
|
int(1)
|
|
bool(false)
|
|
bool(false)
|
|
bool(true)
|
|
int(1)
|
|
bool(true)
|
|
int(1)
|