Re: some DB::quote() options?

From: Date: Sat, 01 Nov 2003 17:17:01 +0000
Subject: Re: some DB::quote() options?
References: 1 2  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-23184@lists.php.net to get a copy of this message
Hi Lukas et al: On Thu, Oct 30, 2003 at 10:04:15PM +0100, Lukas Smith wrote: > > But if ist a NOT NULL field and the pass nothing to DB then maybe it was an > error they would want to spot instead of it silently being interpreted as an > empty string. Then again the same problem exists when you allow null values > and you accidently pass a php null. > > I think we had this suggestion before and it basically said that you would > handle this sort of stuff inside your code to prevent guess work on the part > of DB. > So to be more exact. PEAR DB either lets you manually quote or not quote. > Anything else is upto you. The current system has some problems and requires awkward handling in some cases. First: quote() in the MySQL (and perhaps a few others, I'm not at my office now) version uses PHP's gettype() function. PHP's manual says not to rely on the strings returned by this method. Rather the is_*() functions should be used. Second: Most of the DBMS's rely on the quote() in common.php, which will quote everything, even if it's a numeric type that should not be. The variable type evaluation should happen in the default version too. This will avert inconsistencies when changing database types. Third: Folks may be inputting a numeric variable that's meant to go into a string field, thus the quotes are needed, but mysql::quote() won't put the quotes on. All of theses issues are fairly easy to resolve. I can do the coding for such and provide udiff files. Enjoy, --Dan -- FREE scripts that make web and database programming easier http://www.analysisandsolutions.com/software/ T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y 4015 7th Ave #4AJ, Brooklyn NY v: 718-854-0335 f: 718-854-0409

« previous php.pear.dev (#23184) next »