From: Bill M. <wm...@co...> - 2007-09-04 19:10:47
|
In response to Marc Cousin <cou...@gm...>: > On Tuesday 04 September 2007 20:08:08 Bill Moran wrote: > > In response to "Dan Langille" <da...@la...>: > > > On 3 Sep 2007 at 13:35, Martin Simmons wrote: > > > > >>>>> On Sat, 01 Sep 2007 11:44:03 +0200, Marc Cousin said: > > > > > > > > > > I think you're trying to solve a fake problem here : > > > > > PQescapeStringConn does the job as required, there is no problem > > > > > except a warning. > > > > > > As I understand it, the warning is there to highlight behaviour which > > > will not be accepted in future versions of PostgreSQL. > > > > The warning is there for a reason, as Dan points out, future versions of > > PostgreSQL will _not_ work with the syntax that Bacula uses now, and the > > PGDG is _trying_ to give people ample notice of that. > > > > [snip] > > > > > > > We therefore have three solutions : > > > > > - either we tell postgresql to stop whining (we disable > > > > > escape_string_warning) at the session level (it only means sending a > > > > > 'set escape_string_warning to off' as we start the session) > > > > This is a bad idea, as it will prevent developers from seeing that they're > > using deprecated syntax. > I dont like it either, I only mentionned it for completeness > > > > > > > > - we enable standard_conforming_strings ('set > > > > > standard_conforming_string to on') > > > > This will cause Bacula to _fail_. Bacula does not _use_ standard > > conforming strings, so telling PG to expect them will produce a database > > that Bacula will not understand. > > > > With standard_conforming_strings on, \ has not special meaning, and thus > > will be inserted as-is. If you run the string through the PG escape > > function first, you'll end up with (essentially) a corrupt string. > > > > > > > - we put in the documentation the prerequisite that the administrator > > > > > sets one of those (I don't like this one, as we can do it ourselves) > > > > Which, of course, shares the previous two problems. > > > > > > > In both cases, the code will just work, with every version of > > > > > postgresql... We just have to set one of theses values if they > > > > > exist... > > > > > > > > Yes, that probably a better idea, if they exist, i.e. postgresql 8.2 > > > > onwards. > > > > > > I'm confused. Isn't the use of PQescapeStringConn supposed to avoid > > > such things? > > > > PQescapeStringConn creates strings that are _not_ compliant with the > > SQL standard. Old versions of PG accepted this because it was a > > very common approach to dealing with strange characters (MySQL does > > it as well). It is _not_ compliant with the SQL standard. To improve > > PG's standards-compliance, the PGDB added the E'' syntax, which basically > > tells PG that you're using non-SQL-standard escape syntax, and to expect > > a string that has been passed through PQescapeStringConn. > > Of course not, that's the reason why PQescapeStringConn needs your > connection : it looks at the standard_conforming_strings parameter and > escapes accordingly. That's the whole point of it using your connection ... You may be correct, except that it's not the "whole" point. From the docs, it can "adjust its behavior depending on the connection properties (such as character encoding)" Whether or not those properties include SCS or not is ambiguous at this point. I suppose it's time for me to make some tests ... -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wm...@co... Phone: 412-422-3463x4023 |