Re: [RFC][Discussion] PDO driver specific parsers
| From: | Larry Garfield | Date: | Wed, 17 Apr 2024 19:35:00 +0000 |
| Subject: | Re: [RFC][Discussion] PDO driver specific parsers | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-123153@lists.php.net to get a copy of this message | ||
On Wed, Apr 17, 2024, at 4:19 PM, Matteo Beccati wrote:
> Hey Larry,
>
> Il 17/04/2024 16:51, Larry Garfield ha scritto:
>> This all seems logical, but having separate parsers would mean that the SQL strings are no
>> longer portable, yes? Eg, many frameworks and CMSes try to (claim to) support multiple DBs
>> transparently. (MySQL and Postgres and SQLite, usually). Some even recommend using SQLite for
>> testing, but MySQL for prod. This change would break that, wouldn't it? Because the escaping
>> would necessarily be different for MySQL and SQLite, and thus the queries would break on one or the
>> other?
>
> Nope. If you hardcode strings in your SQL, then it's your responsibility
> to write them with the correct syntax.
>
> For example a
SELECT "foo" will work on MySQL, but
> not on Postgres
> already, and this RFC won't change that.
>
> Likewise, when using single quotes, SELECT '\\' will
> get you a single
> backslash on MySQL right now, but two backslashes on Postgres,
> regardless of this RFC.
>
> The only proper way to safely hardcode literals is to use the
> PDO::quote method, which will take care of all the required
> escaping
> (and charset stuff), according to the connected database. But then
> again, most likely using parameters would be best in many circumstances.
>
> As for recommending testing on SQLite when production is on MySQL, I've
> always found that to be a (huge) foot gun. Of course YMMV ;-)
I did not say I endorse the idea, just that I have seen it done. :-) And some applications purport
to run on your choice of MySQL or Postgres, even if they tend to not test the latter very well.
In any case, good to know that this won't make the situation worse. It's probably a good
idea to include some version of that in the RFC for clarity.
--Larry Garfield