-
-
Save RobThree/4902595d5f8f096f98969e23520d0857 to your computer and use it in GitHub Desktop.
PHP :: Bug #76639 PDO throws PDOException for no apparent reason (https://bugs.php.net/bug.php?id=76639)
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<?php | |
class Result { | |
public $id; | |
public $value; | |
} | |
$pdo = new PDO('mysql:host=localhost;dbname=mydatabase;','myuser','mypass'); | |
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); | |
//$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); | |
$pdo->setAttribute(PDO::ATTR_STRINGIFY_FETCHES, false); | |
$args = [':v'=>null]; | |
$st = $pdo->prepare('select * FROM ( | |
SELECT 1 as id, 103 as value | |
UNION | |
SELECT 2 as id, 556 as value | |
) as faketable | |
WHERE ((:v is null) or (value = :v))'); | |
$st->setFetchMode(PDO::FETCH_CLASS, 'Result'); | |
$st->execute($args); | |
var_dump($st->fetchAll()); |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Apparently, this is "not a bug". While I agree with it being documented and I could've somehow found this (the exception happens at the
execute()
stage, not theprepare()
stage so I didn't read theprepare
documentation that closely) I strongly think a (much) better error message would have been much more helpful.PHP documentation and I often, if not always always, don't seem to get along. Much of it is, IMHO, half-assed, people talking rubbish in the comments or giving excellent tips that should've been in the docs in the first place *, everything is always documented in another place than where I'd expect it and last but not least it looks like a unicorn and a hippo had a baby that shat itself. I guess I'm a spoiled little MSDN brat.
* And when I'm in the docs I clearly need help on something. The docs saying A but people saying B or C isn't very helpful; how do I decide which is correct(er) when I'm there for help in the first place?
But besides that rant (which, naturally, will all be my problem and fault to begin with)...where was I? Oh, right, a helpful error message. How about PDO throws: "Named argument cannot be reused" or "Named argument cannot be used more than once" or something along those lines. That would've saved me hours of debugging, trips to the documentation, building a testcase, reporting it as a bug, getting scolded by some devs for "writing an essay" instead of them appreciating people taking the time to walk them trough the problem etc. and I would've been on my merry-fuckin'-way in 3 seconds after reading such error message.
You pick:
Fatal error: Uncaught PDOException: SQLSTATE[HY093]: Invalid parameter number
Fatal error: Uncaught PDOException: SQLSTATE[HY093]: Named argument cannot be used more than once
You know what would be even better? If PDO allowed this behaviour. I don't see any reason why a named argument cannot be reused. Just so you know: MySQL supports it just fine:
Works fine. Try 103, 556 or 283 for
@x
. Works, again, as expected.So, in summary, the workarounds:
Either way; at the very least the error message could be improved. And, wishful thinking here, the best solution would simply be PDO supporting this scenario. It's not that outlandish.
But PAAMAYIM_NEKUDOTAYIM it. Bug is closed as "Not a bug" and the PHP devs are on their merry way again. Fine. At least this comment in my code now makes sense:
// Can't use :sourceid twice (https://bugs.php.net/bug.php?id=76639) so we use positional here instead of named