>>>>> On Wed, 22 Aug 2007 15:24:32 +0200, Kern Sibbald said: > > 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.
It is client-side -- it only uses the conn to find the encoding, so that it can find the quotes. I don't think any sensible library could make this server-side for the obvious performance reasons you mentioned. __Martin > 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 > ------------------------------------------------------------------------- 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
