>>>>> On Tue, 4 Sep 2007 14:08:08 -0400, Bill Moran said:
>
> 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.
>
> > > > - 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.
I thought that it created strings compliant with the setting of
standard_conforming_strings in the connection, i.e. it should always generate
something that works with '', though you might get warnings if
escape_string_warning is on.
__Martin
> 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.
>
> There are two ways to approach this that would be considered "correct"
> by the PGDG:
> 1) Use the E'' syntax for any string that needs to be escaped. This
> would be good, but is difficult to implement, from my understanding.
> 2) Better would be to switch to the use of PQexecParams(), which does
> not require strings to be escaped. I expect this would be even
> _more_ difficult to implement, but would (in my opinion) be the
> absolutely best way to fix the problem.
>
> --
> Bill Moran
> Collaborative Fusion Inc.
> http://people.collaborativefusion.com/~wmoran/
>
> [EMAIL PROTECTED]
> Phone: 412-422-3463x4023
>
-------------------------------------------------------------------------
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
