>>>>> On Thu, 30 Aug 2007 23:30:37 +0200, Kern Sibbald said:
> 
> 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.

Yes, that's what I meant really, but the caller should not even try to
allocate what it thinks is the right size because only db_escape_string knows
that.


> > 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.

It would be nice to avoid that.  The meaning of % could be modified:

%q1 ->   quoted and escaped
%1  ->   not quoted or escaped

The uses of '%1' would then be changed to %q1 etc.  The uses %1 for jobids etc
(which should not be passed to db_escape_string anyway) would remain the same.

__Martin

-------------------------------------------------------------------------
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

Reply via email to