On 4 Sep 2007 at 16:26, Bill Moran wrote: > In response to "Dan Langille" <[EMAIL PROTECTED]>: > > [snip] > > > > > > > > > > You may be correct, except that it's not the "whole" point. From the > > > > > docs, it can "adjust its behavior depending on the connection > > > > > properties > > > > > (such as character encoding)" > > > > > > > > > > Whether or not those properties include SCS or not is ambiguous at > > > > > this > > > > > point. I suppose it's time for me to make some tests ... > > > > > > > > I had already done them a while ago :) (see below) > > > > > > Ahh ... shame on me for not following the thread more carefully. > > > > > > So, the problem becomes that db_escape_string() does not take a > > > connection object as a parameter, and making it do so would require > > > some substantial mucking about in the various files in the src/cats > > > directory ... > > > > I have code here that changes db_escape_string to take a connection > > parameter. It was my testing of those patches that found this > > problem and started this thread. > > Well, Kern and I discussed this back in early July on bacula-beta, > and the comment that made me assume it was taken care of was > "There is no > problem doing something special for PostgreSQL, so we really don't care what > MySQL does. MySQL has a system API that does the escaping for you. Each SQL > engine can have its own string escape routine." > > I suppose I should have been more diligent in following up at the time. > > > It seems that using > > PQescapeStringConn is insufficient to avoid the warning "WARNING: > > nonstandard use of escape in a string literal". > > I'm confused by this statement. Are you referring to the fact that > your patch checks the return code and errors on invalid multibyte > encoding?
No. I mean the escaping that PQescapeStringConn does fails to transform the string into something that avoid the warning. My original post: http://marc.info/?l=bacula-devel&m=118850029319839&w=2 The issue is not that the query returns zero rows. This query is just for testing the warnings. Running the weird file name regression test, there is a file named: a-file-with-a-slash\-in-itlocalhost-dir PQescapeStringConn escapes that filename to: a-file-with-a-slash\\-in-itlocalhost-dir With that filename the regression test still reports the original warning: WARNING: nonstandard use of \\ in a string literal > If so, that's an interesting problem. Apparently even UTF-8 has > certain byte sequences that are invalid, and PG is fussy about > rejecting them. I've frequently wondered why Bacula doesn't use > PG's SQL_ASCII encoding (which allows any string without validation) > to avoid this kind of thing. The question is how much sanity > checking Bacula does on the UTF-8 string, and how confident we are > that it will never submit an invalid UTF-8 byte sequence. > > At least, that's if I understand your previous statement. > > > The patch, which contains debugging code which should not be > > committed, can be found at: > > > > http://www.langille.org/tmp/bacula-escape.diff The problem, as I see it, is that -- Dan Langille - http://www.langille.org/ Available for hire: http://www.freebsddiary.org/dan_langille.php ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
