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 ...
> Sorry, by 'the whole point', I meant that the function uses the connection to
> know exactly how you're setup (encoding, standard_conforming_strings...), and
> does the escaping intelligently, instead of a dump escaping as was done by
> PQescapeString. And that's the whole point of giving it your connection...
>
>
> The code :
> #include "/usr/include/postgresql/libpq-fe.h"
> #include <stdio.h>
>
> main()
> {
> PGconn *conn;
> char result[255];
> char* query="to'to\\titi";
> int error;
>
> conn=PQconnectdb("host=localhost dbname=bacula user=postgres");
>
> PQescapeStringConn(conn, result, query , strlen(query) ,&error);
> printf("%s\n",query);
> printf("%s\n",result);
> }
>
>
>
> Here are the results of the test :
>
> Standard_conforming_strings = off
> to'to\titi
> to''to\\titi
>
> Standard_conforming_strings = on
> to'to\titi
> to''to\titi
>
--
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
