PDO: No exception when wrong data is bound to statement

[butesa]

Description

The following code:

<?php

declare(strict_types=1);

$pdo = new PDO('mysql:host=localhost;dbname=demo;charset=utf8mb4', 'user', 'pass');
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

$pdo->exec('DROP TABLE IF EXISTS test');
$pdo->exec('CREATE TABLE test (mode TINYINT)');

$statement = $pdo->prepare('INSERT INTO test (mode) VALUES (?)');
$statement->bindValue(1, new DateTime(), PDO::PARAM_INT);

$success = $statement->execute();
$error = $pdo->errorInfo();

var_dump($success);
var_dump($error);

Resulted in this output:

bool(false)
array(3) {
  [0]=>
  string(5) "00000"
  [1]=>
  NULL
  [2]=>
  NULL
}

But I expected this output instead:
An unsuccessful PDO command should throw an exception.

PHP Version

PHP 8.1.2

Operating System

Ubuntu 22.04.3

[devnexen]

what happens if you set the following ?

...
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
...

[SakiTakamachi]

I reproduced it. I'll take a closer look.

[SakiTakamachi]

If the parameter type is an object, it passes through here, so it returns false without setting an error.

php-src/ext/pdo_mysql/mysql_statement.c

Line 534 in d5dae8b

PDO_DBG_RETURN(0);

I check what other drivers are doing.

[SakiTakamachi]

Other bundled drivers (I haven't looked at pdo_oci) have either given errors or warnings.

IMHO, the fix should be done on master, as it could result in a BC break. If possible, I would like to unify whether it is an error or a warning...

With warnings, 1 was saved. If we standardize so that an error occurs, the data will not be saved. (I don't know if the 1 saved is worth it.)

PDO::ATTR_EMULATE_PREPARES = false

Driver	Result
pdo_mysql	No error and warning
pdo_pgsql	Fatal error: Uncaught Error: Object of class DateTime could not be converted to string
pdo_firebird	Fatal error: Uncaught PDOException: SQLSTATE[HY105]: Invalid parameter type: -999 Binding arrays/objects is not supported
pdo_sqlite	Warning: Object of class DateTime could not be converted to int
pdo_odbc	Fatal error: Uncaught Error: Object of class DateTime could not be converted to string
pdo_dblib	Warning: Object of class DateTime could not be converted to int

PDO::ATTR_EMULATE_PREPARES = true

Driver	Result
pdo_mysql	Warning: Object of class DateTime could not be converted to int
pdo_pgsql	Warning: Object of class DateTime could not be converted to int
pdo_firebird	Fatal error: Uncaught PDOException: SQLSTATE[HY105]: Invalid parameter type: -999 Binding arrays/objects is not supported
pdo_sqlite	Warning: Object of class DateTime could not be converted to int
pdo_odbc	Fatal error: Uncaught Error: Object of class DateTime could not be converted to string
pdo_dblib	Warning: Object of class DateTime could not be converted to int

[kamil-tekiela]

It should always trigger this warning:

Warning: Object of class DateTime could not be converted to int

This is because that's the defined behaviour when an object cannot be converted to int:

<?= (int) new DateTime();

I don't know why some drivers are trying to convert it to a string, but if that's the intended behaviour then they should indeed throw an error:

Object of class DateTime could not be converted to string

This is just how PHP currently defines this behaviour. The warning when casting to int should probably be promoted to an error at some point in future, but obviously bug fixing is not the right time to discuss this.

Firebird is interesting in that it completely disallows binding objects. I don't know the reason for this, but if it should be allowed then it would be a separate bug on its own.

So IMHO if you want to fix the bug, take a look at what happens in PDO_MySQL as it seems to be the only one with an invalid behaviour at the moment.

[SakiTakamachi]

I don't know why some drivers are trying to convert it to a string, but if that's the intended behaviour then they should indeed throw an error:

As a fallback, some drivers attempted to convert to a string if the parameter type was not one of the expected.

Firebird is interesting in that it completely disallows binding objects. I don't know the reason for this, but if it should be allowed then it would be a separate bug on its own.

This is probably not a problem in the current. This can become a problem when resource types are replaced by objects, but we'll probably shouldn't discuss this now.

So IMHO if you want to fix the bug, take a look at what happens in PDO_MySQL as it seems to be the only one with an invalid behaviour at the moment.

Well, first of all, we should correct the clearly outcast behavior.

Personally, in the case of current mysql, data cannot be inserted, so I think it would be fine to prepare a fallback like pgsql and make it an error, but I would like to hear your opinion.