From: ldo@nz.invalid   
      
   On Tue, 8 Jul 2025 21:54:20 -0400, Arne Vajhøj wrote:   
      
   > On 7/8/2025 7:38 PM, Lawrence D'Oliveiro wrote:   
   >>   
   >> On Tue, 8 Jul 2025 18:40:31 -0400, Arne Vajhøj wrote:   
   >>>   
   >>> Dynamically creating SQL string where the dynamic part is for data   
   >>> is a security disaster waiting to happen (and possible poor   
   >>> performance as well).   
   >>   
   >> That’s a pretty naïve statement to make.   
   >>   
   >> Quoting literal data in standard SQL is quite simple: turn the data   
   >> into a string literal with single quotation marks, and any embedded   
   >> single quotation marks are written twice. That’s it. Every other   
   >> character can be represented as itself, literally.   
   >   
   > It is an assumption that all developers remember to do it right.   
      
   It’s not just literal strings. Other constructs need escaping, too.   
      
   >    
   > Defense Option 4: STRONGLY DISCOURAGED: Escaping All User-Supplied Input   
   >    
      
   Unfortunately, you often have no choice.   
      
   > Very few API's does not allow prepare/parameters ...   
      
   None of them include support for all the necessary cases.   
      
   > Because mysql extension did not support prepare/parameters   
   > they first added a mysql_escape_string function to do what one   
   > think should be done.   
   >   
   > $s = mysql_escape_string($s);   
   >   
   > But clever people found out that the argument list was   
   > wrong.   
      
   That was just the usual PHP brain damage. Others were able to do it   
   right from the beginning.   
      
   > error_reporting(E_ERROR);   
      
   Here’s another example of PHP brain damage: the fact that reporting   
   SQL errors is *optional*!   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)