Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114018 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 38589 invoked from network); 10 Apr 2021 22:33:47 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 10 Apr 2021 22:33:47 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 53D731804B3 for ; Sat, 10 Apr 2021 15:33:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 10 Apr 2021 15:33:52 -0700 (PDT) Received: by mail-qt1-f175.google.com with SMTP id i19so7100279qtv.7 for ; Sat, 10 Apr 2021 15:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v35vGL3xN3+vX9eOf1z1uO/8iiyxjmncL/zz+0CY4mY=; b=iwjzkp2aGO+xSGPZgF7KmsgCs4NsUFsBRvhDHZLTaWvKE4hXkq15466fWQxQ/UAEOG lbLsfd9A8OwfEDwDiKpzqviQ6NwQ7Fdby72j4Uh6vJCz8DuhggyMlJNZIo9URVTuGB2I AF5Ey8BYkbBSeHF9FXsRsh1lpjGcmqQferJPSV8Z8hPPYeoVkPaNvv1JK9uZ1nA0va9K mEUAXx7SzNUcqmC3tAR4nS8rFfRBiG53dGxJzsdwnj+d7dqGb6lnYhqyKjBIqr+FBqdD sB5sCZP4Ca/J6XAThUjxF2wZSApyiiHbDTzAvsX8ChlqiHsGRQUEJobGlkC6i21F6wiG NLoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v35vGL3xN3+vX9eOf1z1uO/8iiyxjmncL/zz+0CY4mY=; b=iT6Pw3e92UC1XeDBlCuhq35Ld5kBVcNZU4NkcYHKBlm6bHz2D9uhWwW+qMYA8jbUHt 2yHuDUVZKOZDu6Zta2F3H8ik2wYC1oA1HOYT9aE57DYgkWJnuO43LWg+VE/ZOqtMgLTF AXTOqZpfYUN6i54iCIlQ/1LRpw0oG+x7Emd8lylBWgPhFdDOEPcO8UDwvt7GbApK4Lv9 GjFNxIFijtpLQe6NzwlFLmPYLM4zz+hbaEy4wKFCTM0qIw107D9mmxoII0wLbMLDqb/+ xZ8aOxcRHQOR95TNcQMouo5Q/lsqeP8Jin+N2fsYBe9UmwWN1SBySSFxPxJEwYBQ002t 74QQ== X-Gm-Message-State: AOAM532jQz5zElVF3315N6qrK4KQy5JguGDqVuOytMem/4/AKtXRAIM9 UH91mtMcLhe1u3RvLenkG2anx7FExq2ILRWNYpY= X-Google-Smtp-Source: ABdhPJxMXJkIhA2ThVETgMj2ilBzcQGNEZ+bQPKety7SpzgGvM8tkSfkH2sC12t8EWqubtL3EC+72zE44u9j7GFo/5U= X-Received: by 2002:ac8:7a77:: with SMTP id w23mr2917379qtt.277.1618094031292; Sat, 10 Apr 2021 15:33:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Sat, 10 Apr 2021 23:33:41 +0100 Message-ID: To: Sergei Morozov Cc: PHP Internals Content-Type: multipart/alternative; boundary="000000000000f2ccb405bfa5dfef" Subject: Re: [PHP-DEV] Use MySQL syntax only for parsing MySQL statements in PDO From: tekiela246@gmail.com (Kamil Tekiela) --000000000000f2ccb405bfa5dfef Content-Type: text/plain; charset="UTF-8" This is an interesting solution to the problem, but I am unsure if it's the best one. I didn't look into it in detail yet, but at first glance, it seems to be a cheap hack to solve a bug. What about backtick character ` ? What about NO_BACKSLASH_ESCAPES mode? Any question mark within backtick-escaped column name would still cause a problem. In fact, when I tested it with NO_BACKSLASH_ESCAPES the PR didn't fix the problem. I got a different error, but the problem still exists. This is a naive solution that fixes one tiny bug in a single driver with no regards for tons of other issues. I am against adding such hacks into the PHP source code. What we need is a full SQL parser that is context-aware. This task should be delegated to the PDO drivers. PDO can't do it reliably at the base level. The problem is that PDO is never going to be able to reliably parse the SQL even if we have a separate parser for each driver. PDO is not the server and it doesn't know how the SQL will be parsed at the end of the day. At its root, it seems to be an unfixable problem. Emulated prepares have a lot of issues and this is only one of them. The solution is to use native prepares whenever they are available on the server. If you want you can see the effect your PR has on this test case: $pdo = new \PDO("mysql:host=localhost;dbname=test;charset=utf8mb4", 'user', 'password', [ \PDO::ATTR_ERRMODE => \PDO::ERRMODE_EXCEPTION, \PDO::ATTR_EMULATE_PREPARES => true ]); $pdo->exec("SET sql_mode = NO_BACKSLASH_ESCAPES;"); $stmt = $pdo->prepare("SELECT * FROM foo WHERE text='\' and 1=? and text='\'"); $stmt->execute([1]); I'm sorry but this is a hard pass from me. --000000000000f2ccb405bfa5dfef--