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. 

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 ...

Regards,

Kern

-------------------------------------------------------------------------
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

Reply via email to