On Wednesday 22 August 2007 14:06, Dan Langille wrote: > On 22 Aug 2007 at 13:57, Kern Sibbald wrote: > > On Wednesday 22 August 2007 13:06, Dan Langille wrote: > > > On 22 Aug 2007 at 10:35, BOLLENGIER Eric wrote: > > > > On Wednesday 22 August 2007 02:58:15 Dan Langille wrote: > > > > > On 21 Aug 2007 at 23:34, Eric Bollengier wrote: > > > > > > Hello, > > > > > > > > > > > > Yes, bacula is using PQescapeString which is an older, deprecated > > > > > > version of PQescapeStringConn. We have to use the new version to > > > > > > avoid this message, but it's not so easy at this time :) > > > > > > > > > > > > It's in my todo list. > > > > > > > > > > I'll do it. > > > > > > > > Ok, you have to modify the db_escape_string prototype > > > > to something like > > > > > > > > db_escape_string(B_DB *mdb, char *snew, char *old, int len) > > > > > > > > to be able to use mdb->db in PQescapeStringConn. > > > > > > I'll start this today. > > > > > > Kern: I'm thinking this does not need to be on a different branch. > > > > By the way, I am not 100% convinced that we need to use > > PQescapeStringConn, though it is probably best for the long term. If I > > am not mistaken, the basic problem is not that PQescapeString does not > > work, but that what PostgreSQL wants is a string that looks like: > > > > E'string-with-escapes' > > > > and what we feed it is: > > > > 'string-with-escapes' > > > > So, the error messages can be eliminated by modifying the code slightly. > > The biggest problem is that the basic core code expects a char * string, > > and then in many different places encloses it in single quotes, and the > > new code needs to leave the addition of single quotes up to the lower > > level subroutine. > > Are you saying there is more to this than just invoking > PQescapeStringConn from within db_escape_string? I think you may be > saying that some other parts of the Bacula code needs to be altered > other than just our db_escape_string function.
I think there is a lot more to it than just calling PQescapeStringConn. In the first place, doing so would probably be a *very* significant performance hit *if* the code actually is present in the server. If it is in the client library, there is no performance problems. PQescapeStringConn is needed to ensure that the input string is converted to the database text string encoding, but Bacula *knows* that the database encoding is UTF-8, otherwise Bacula is not going to work, so the routine is not really needed. What is needed is simply code that does the appropriate quoting, then ensures that PostgreSQL knows that it is an escaped string. Apparently PostgreSQL wants to uphold the SQL standard which calls for escaped strings to be encoded as I mention above. For example, MySQL should be using mysql_real_escape_string() rather than the mysql_escape_string() that it uses. The problem is identical to the PostgreSQL problem. SQLite may have some similar problem. The current code in SQLite does the escaping in Bacula code. I think this a bit of research and experimenting or reading MySQL/PostgreSQL client library code so that it can be done correctly in all the SQL engines. Regards, Kern PS: I have just added two new calls in dird/ua_restore.c to db_escape_string() to fix bug #930. I will commit after running the appropriate regression test later tonight or tomorrow morning. ------------------------------------------------------------------------- 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
