Dit lijkt mij een (niet gerapporteerde?) bug in PDO's voorbereide emulatie van verklaringen:
-
de implementatie van
PDOStatement::execute()uiteindelijk roeptpdo_parse_params()op ; -
dat op zijn beurt probeert om waarden aan te halen/te ontsnappen gebaseerd op het gegevenstype van de relevante parameter (zoals aangegeven door de
$data_typeargumenten voorPDOStatement::bindValue()enPDOStatement::bindParam()—alle parameters geleverd als$input_parametersnaarPDOStatement::execute()worden behandeld alsPDO::PARAM_STR, zoals vermeld in de documentatie van die functie); -
string-getypte waarden worden escaped/geciteerd door aanroepen
quoter()methode, ongeacht of zenull. zijn :in het geval van PDO_MySQL is datmysql_handle_quoter(), die (uiteindelijk) de waarde doorgeeft aanmysqlnd_cset_escape_quotes()ofmysql_cset_escape_slashes(), afhankelijk van deNO_BACKSLASH_ESCAPESvan de server SQL-modus; -
gegeven een
nullargument, geven beide functies een lege string terug.
Mijn mening is dat, voorafgaand aan het inschakelen van de parameter typ
(in stap 2 hierboven), pdo_parse_params() moet het type instellen op PDO::PARAM_NULL als de waarde null . is . Sommigen zouden echter kunnen beweren dat dit typespecifieke verwerking van null . zou voorkomen waarden waar van toepassing, in welk geval de string case (in stap 3 hierboven) moet zeker null verwerken waarden voordat u doorgaat met een oproep naar de quoter() van de bestuurder methode.
Als tijdelijke oplossing is het meestal toch het beste om de emulatie van voorbereide verklaringen uit te schakelen:
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, FALSE);