On 4 Sep 2007 at 15:45, Bill Moran wrote:
> In response to Marc Cousin <[EMAIL PROTECTED]>:
>
> > On Tuesday 04 September 2007 21:10:34 Bill Moran wrote:
> > > In response to Marc Cousin <[EMAIL PROTECTED]>:
> > > > On Tuesday 04 September 2007 20:08:08 Bill Moran wrote:
> > > > > In response to "Dan Langille" <[EMAIL PROTECTED]>:
> > > > > > 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 ...
> >
> > I had already done them a while ago :) (see below)
>
> Ahh ... shame on me for not following the thread more carefully.
>
> So, the problem becomes that db_escape_string() does not take a
> connection object as a parameter, and making it do so would require
> some substantial mucking about in the various files in the src/cats
> directory ...
I have code here that changes db_escape_string to take a connection
parameter. It was my testing that found this problem and starting
this thread.
--
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
