Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109143 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 23152 invoked from network); 19 Mar 2020 13:58:32 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 Mar 2020 13:58:32 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 70ADC1804F3 for ; Thu, 19 Mar 2020 05:21:41 -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.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS1836 195.49.0.0/17 X-Spam-Virus: No X-Envelope-From: Received: from darkcity.gna.ch (darkcity.gna.ch [195.49.47.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 19 Mar 2020 05:21:40 -0700 (PDT) Received: from flatter.home (unknown [IPv6:2a02:120b:c3f7:5090:add6:db90:3b83:535d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id 5F1816C1516; Thu, 19 Mar 2020 13:21:38 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) In-Reply-To: Date: Thu, 19 Mar 2020 13:21:37 +0100 Cc: "Christoph M. Becker" , PHP internals Content-Transfer-Encoding: 7bit Message-ID: <6767EEB7-FEE0-4DB7-964F-C41CD86AFEB0@cschneid.com> References: <7b073954-74ea-7877-97dc-dbf87d4f3e8a@gmx.de> To: Matteo Beccati X-Mailer: Apple Mail (2.3608.60.0.2.5) Subject: Re: [PHP-DEV] PDO parser: drop support for backslash escapes From: cschneid@cschneid.com (Christian Schneider) Am 19.03.2020 um 09:38 schrieb Matteo Beccati : >> I think we should completely drop support for backslash escapes in the >> PDO parser as of PHP 8. If it was possible to support these without >> breaking other standard conforming SQL queries, it would be nice to keep >> it, but that doesn't seem to be possible. >> >> Thoughts? > > Thanks for bringing it up. I suppose it's about time to start conforming > to the SQL standards, but maybe we should have gone through a > deprecation stage first? I second this. - Chris