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
