On 5 Sep 2007 at 18:47, Kern Sibbald wrote:
> On Wednesday 05 September 2007 18:03, Dan Langille wrote:
> > On 5 Sep 2007 at 0:00, Kern Sibbald wrote:
> > > On Tuesday 04 September 2007 19:42, Dan Langille wrote:
> > > > 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 reason for this is the following :
> > > > > > You're asking postgresql to :
> > > > > > - Use non-standard conforming strings (aka old postgresql way of
> > > > > > doing things) - Do a conversion of your string (containing a \) to
> > > > > > the string format that should be used -> a second \ is added
> > > > > > - Then insert this string, asking postgresql to warn you when you
> > > > > > use non-standard conforming string. Of course, the server tells you
> > > > > > you have an escaped \...
> > > > > >
> > > > > > You're not explicitely asking for it, it's the default setup ...
> > > > > >
> > > > > > What I think is the right way of solving the problem is this one
> > > > > > ...
> > > > > >
> > > > > > We KNOW we use the right conversion function : we use the
> > > > > > conversion function provided by postgresql, and this function reads
> > > > > > the standard_conforming_string value for the session used, and does
> > > > > > what's required to have the data in the right format. Of course, it
> > > > > > doesn't prevent the server from whining because your string isn't
> > > > > > beautiful :)
> > > > > >
> > > > > > 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) - we
> > > > > > enable standard_conforming_strings ('set
> > > > > > standard_conforming_string to on')
> > > > > > - 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)
> > > > > >
> > > > > > 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?
> > >
> > > Yes, it generates correct strings, but how can PostgreSQL know that
> > > unless the string is prefixed with E'..., which is a royal pain, or
> > > you explicitly tell PostgreSQL that you have done it right, which is
> > > what Marc is suggesting.
> >
> > The E'...' syntax confused me at first. It appears to involve
> > prefixing the string with E. That's it. I thought it was based
> > around embedded E into the middle of the string. But it is more
> > simple than I thought. Example follows.
> >
> >
> > regress=# SELECT FilenameId FROM Filename WHERE Name='a-file-with-a-
> > slash\\-in-itlocalhost-dir';
> > WARNING: nonstandard use of \\ in a string literal
> > LINE 1: SELECT FilenameId FROM Filename WHERE Name='a-file-with-a-
> > sl...
> > ^
> > HINT: Use the escape string syntax for backslashes, e.g., E'\\'.
> > filenameid
> > ------------
> > (0 rows)
> >
> > regress=# SELECT FilenameId FROM Filename WHERE Name= E'a-file-with-a-
> > slash\-in-itlocalhost-dir';
> > filenameid
> > ------------
> > (0 rows)
> >
> > The only change to the string is a prefix of E
>
> Yup. However, doing so in Bacula would be quite disruptive since the single
> quotes are all embedded in SQL printf like commands as
> "SELECT .... xxx='%s' ..." so it is not just a simple matter of making
> db_escape_string return the full "quoted" string. One would have to modify
> *all* the places where the string is editted into the command. That's why I
> like Marc's solution.
Noted.
> By the way, if you would like to carry this to the very end, I can send you
> the details of what Marc recommends doing to eliminate the warning
> messages ...
Sure.
--
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
