In response to "Dan Langille" <[EMAIL PROTECTED]>: > 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.
Ah ... I see. If conforming strings was on, this would work just fine, but since it's off (which is still the default anyway) it still warns us about it. Actually, it _works_ fine either way. It just emits a lot of warnings if conforming strings is off. Marc's email makes considerably more sense at this point. Given that I now actually understand the topic, I'd be in favor of turning off escape_string_warning at session start. Sorry for the extra noise on my part -- it seems I broke the rule of not reading the entire thread before responding. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ------------------------------------------------------------------------- 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
