Bug #80340 [Opn->Dup]: PDO incorrectly parses string literals for platforms other than MySQL

From: Date: Sun, 08 Nov 2020 21:35:29 +0000
Subject: Bug #80340 [Opn->Dup]: PDO incorrectly parses string literals for platforms other than MySQL
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-230207@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=80340&edit=1 ID: 80340 Updated by: cmb@php.net Reported by: morozov at tut dot by Summary: PDO incorrectly parses string literals for platforms other than MySQL -Status: Open +Status: Duplicate Type: Bug Package: PDO Core Operating System: Linux PHP Version: 7.4.12 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: Duplicate of bug #79276. Previous Comments: ------------------------------------------------------------------------ [2020-11-08 19:31:42] morozov at tut dot by Description: ------------ When extracting prepared statement parameters, the SQL parser doesn't take into account the dialect of the currently used database platform. Specifically, it unconditionally expects string literals to use backslash for escaping the closing delimiter (single or double quote), although it's only supported by MySQL. It causes incorrect query parsing on other platforms (e.g. PostgreSQL). In the following script, the parser interprets the combination of the backslash and the quote as part of the literal, so the following question mark gets replaced with the $1 placeholder, however, it should remain intact as part of the literal. Test script: --------------- $conn = new PDO('pgsql:...'); $sql = <<<'SQL' SELECT '\'', ?' SQL; $stmt = $conn->prepare($sql); $stmt->execute(); var_dump($stmt->fetchColumn()); Expected result: ---------------- postgres=# SELECT '\'', ?'; ?column? ---------- \', ? (1 row) Actual result: -------------- \', $1 ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=80340&edit=1

« previous php.bugs (#230207) next »