On 6/12/08, Tim Johnson <[EMAIL PROTECTED]> wrote: > On Thursday 12 June 2008, Warren Young wrote: > > Tim Johnson wrote: > > > Not sure what you mean by "directly usable". > > > > I mean "directly usable". :) > > > > > If I do an insert statement with a backslash, for example: > > > "headline\one", I will retrieve "headline\\one", and that will > > > need to be unescaped, because it is not a true representation > > > of what was submitted by the original insert. > > > > My perspective is a little different from yours: as the maintainer of > > MySQL++ (http://tangentsoft.net/mysql++/), I have never actually used > > the C API directly. I don't have any pure C sample code here to tweak > > to try things. > Me neither - not any more anyway, since I quit coding in C & C++ years ago.. > Furthermore, I am also working with a scripting language new to me. > My experience is with python - where unescaping is _not_ an issue and > rebol, where unescaping _is_ an issue. Python using the API (somewhere > buried deep in the MySQLdb modules, and rebol using a direct socket > connection on port 3306. > > > Instead, I changed one of the MySQL++ examples to insert a string with a > > backslash into the DB, and on retrieving the rows, I get a single > > backslash. In the C++ code, the backslash is doubled due to C/C++ > > string parsing rules, but that's only one character in the underlying > > string data. Due to the way this example uses MySQL++, that string gets > > automatically escaped on DB insertion, so I presume it's sent over the > > wire as two backslashes, though I haven't verified it. Then when you > > retrieve rows through MySQL++, it returns a fairly direct copy of the > > data the C API gives you, with no real translation going on. > I'm seeing the same that you are with the language (newlisp) that I am > "playing" with. > > > > MySQL++ doesn't have an "unescape" function, so I don't see why your > > program would need one. > I believe that you are correct. If not a single regex should handle it, and > be fairly fast. > Thanks for the input. I really appreciate it. > Best regards > tim(looking at MySQL++)
The same is true of mysql_real_escape_string() in PHP. You escape special characters upon update or insertion, but upon viewing the data in the DB or retrieving it programmatically, the data simply appear as it was originally before use of the function. David -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
