In response to Kern Sibbald <[EMAIL PROTECTED]>: > On Thursday 30 August 2007 22:12, Martin Simmons wrote: > > >>>>> On Thu, 30 Aug 2007 14:57:27 -0400, Dan Langille said: > > > > > > It seems that PQescapeStringConn is insufficient to avoid the warning > > > "WARNING: nonstandard use of escape in a string literal". I'm > > > running the regression tests. > > > > > > a-file-with-a-slash\-in-itlocalhost-dir > > > becomes > > > a-file-with-a-slash\\-in-itlocalhost-dir > > > > > > regress=# SELECT FilenameId FROM Filename WHERE Name='a-file-with-a- > > > slash\\-in-itlocalhost-dir'; > > > WARNING: nonstandard use of \\ in a string literal > > > LINE 1: SELECT FilenameId FROM Filename WHERE Name='a-file-with-a- > > > sl... > > > ^ > > > HINT: Use the escape string syntax for backslashes, e.g., E'\\'. > > > filenameid > > > ------------ > > > (0 rows) > > > > > > regress=# > > > > > > Any ideas how to use the E'\\' syntax? > > > > > > FYI, this works: > > > > > > regress=# SELECT FilenameId FROM Filename WHERE Name='a-file-with-a- > > > slash' || E'\\' || '-in-itlocalhost-dir'; > > > filenameid > > > ------------ > > > (0 rows) > > > > > > regress=# > > > > > > I'd rather use PostgreSQL functions instead of rolling my own. > > > Suggestions? Ideas? > > > > Not quite sure what you mean by "how to use". Was that select statement > > supposed to return 0 rows? > > > > If you mean how to modify Bacula to use E'\\' syntax, then db_escape_string > > will probably have to change to create the complete E'...' string instead > > of just returning the ... part. This requires changes to all of the > > callers (which currently add their own quotes) and to the other db backends > > to return '...' as well. > > Yes, exactly. If I am not mistaken, I mentioned the above to Dan in one of > the > older emails we had on this subject. > > > The memory allocation for the resulting string > > will need to be fixed and is probably best done by db_escape_string itself, > > with appropriate freeing by the caller. > > That is forbidden or highly discouraged within Bacula code as it is IMO a > formula for guaranteeing that there will be memory leaks at some point. The > Bacula way of handling this is to allocate a string in the calling code that > can be resized in the db_escape_string routine, if necessary, as is done in > *many* other places within Bacula. > > > Some hack will have to be done for the substitutions in the query.sql file. > > More likely we will separate query.sql into PostgreSQL "standard" SQL, and > query.sql real world SQL separate files.
Could much of this be solved by switching to PQexecParams instead of PQexec? http://www.postgresql.org/docs/8.2/static/libpq-exec.html#LIBPQ-EXEC-MAIN PQexecParams does not require that strings be escaped at all, so the escaping functions in Bacula can basically become null functions. However, it does have a radically different calling syntax, which may make the fix harder. I haven't had time to look at the code. -- 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
