On 22 Aug 2007 at 15:24, Kern Sibbald wrote: > 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.
I think the right thing to do is use PQescapeStringConn in the PostgreSQL module. Similary, the MySQL module should be similarly altered. Use the vendor supplied quoting mechanism is the best thing to do from a long-term support point of view. It is client-side code, for it would be a huge performance hit to do it server-side. The PG team are pretty good in that regard. > 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. Good. I haven't run any regressions tests yet, but I have ensured that the changes I made to add the B_DB parameter to db_escape_string() didn't break anything. I compiled, ran a restore, and a backup, no problems. I plan to implement a fully automated daily regression test as soon as I can. This will be initially for FreeBSD, but if I can get VMWare or similar installed/running, I could do this for any number of OS. -- 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
