Re: Bugs in PEAR::DB

cox@idecnet.com (Tomas V.V.Cox) wrote in news:01071120093301.08889 @router.vulcanonet.com: > On Wednesday 11 July 2001 17:16, you wrote: >> >> > Yes, this is true. What is the solution here? Detect if >> > magic_quotes are set, unquote the string and pass it to $db->quote >> > (who should quote according the backend)? >> >> Many users rely on magic_quotes to ensure that all the data that's >> passed in is quoted... >> >> How about putting in an optional flag to DB::common::prepare() that >> specifies whether the passed-in information should be quoted or not?... > > I think we are mixing concepts. Magic_quotes only adds slashes and is > not a good quote system for inserting it in queries. For example: > a string like: > --hello "this is 'a string-- > might be quoted by magic_quotes_gpc: > --hello \"this is \'a string-- > while for example PostgreSQL needs: > --hello "this is ''a string-- > > This is why I think that people should quote the data with native > $db->quoteString() instead of relaying in magic_quotes. Also in the > magic_quotes doc says that it will escape NULs (I don't know what that > means) while we need to transform a null (php constant) value to a > "NULL" string. NULs are 0 ASCII value characters (i.e. 0x00) and are not PHP 'null' constant values. I.e. a NUL character on its own would probably be interpeted as zero or FALSE by PHP. As someone else pointed out, there's another option in PHP that enables PostgreSQL or Sybase behavior for magic_quotes. Point is, users are usually aware of what kind of quoting behavior their database needs. For example, I'm using MySQL and I *know* that magic_quotes takes care of all my quoting needs. > Any way, in the "draft" I told you after, I proposed to add a new > placeholder "!" that will leave unchanged the supplied string (without > call $db->quoteString()). After reading your draft, my impression is that not only does '!' leaves the supplied string unchanged, but it also does not add the quotes around a value. In other words, currently ? is replaced with "'quoted-value'" while ! you propose is replaced with just "original-value". I guess it's not a biggie to specify SET x='!' instead of SET x=? in the prepare query, so I'm fine with that :). This ! placeholder would solve my problem :) However, consider the case of someone developing an application under PHP with magic_quotes disabled, and using PEAR::DB's prepare/execute. Thus, that person is relying on prepare/execute auto-quoting the ?-placeholder data. Suddenly, the application must be deployed on a server/host that has magic_quotes on and does not allow INI changes. Thus, the developer is forced to alter the code to suit the situation. Does the developer: 1) add removeslashes (or whatever the function is) to undo magic_quotes 2) replace all ? with '!' in the SQL queries for prepare 3) enable a switch in every prepare to drop quoting on ? 4) enable a switch application-wide in DB (sorta like that optimized for speed/portability switch) to drop quoting on ? Right now, the only option is #1. - Oleg