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_type
argumenten voorPDOStatement::bindValue()
enPDOStatement::bindParam()
—alle parameters geleverd als$input_parameters
naarPDOStatement::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_ESCAPES
van de server SQL-modus; -
gegeven een
null
argument, 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);