On 2012-09-27 at 11:40 +0100, Jeremy Harris wrote:
> On 09/27/2012 03:32 AM, Phil Pennock wrote:
> > On 2012-09-26 at 17:30 +0200, Micha Lenk wrote:
> >> So, given that the Perl module DBD::Pg dropped the escaping of these
> >> characters already some years ago (CPAN RT #27538), what are the reasons
> >> to keep this useless escaping of percent and underscore in future Exim code?
> >
> > Confirmation that the relevant code change is adequate. :)
> >
> > So, src/lookups/pgsql.c in function pgsql_quote(), around line 463, you
> > should find:
> >
> > else if (Ustrchr("\n\t\r\b\"\\%_", c) != NULL)
> >
> > If you remove the % and _ from that string, does that fix the problem
> > for you?
> >
> > By my reading of the code, that's all that's required.
>
> How will exim know that postgres is set up with standards-conforming-strings?
> Will we need to provide an alternate quoter? A mode-switch?
My understanding was that %_ were harmless in previous versions and
escaping them was a harmless noop, until version 9.1 turned on
"standard_conforming_strings" by default. Have I misunderstood?
If I have, then how about, in perform_pgsql_search(), after the
PQsetNoticeProcessor() call, we do:
pg_result = PQexec(pg_conn, "set standard_conforming_strings = on");
if (!pg_result) { /* XXX: error handle serious OOM issue */
switch(PQresultStatus(pg_result)) {
case PGRES_EMPTY_QUERY:
case PGRES_COMMAND_OK:
/* set successfully, nothing to do */
break;
default:
/* assume this is a very old PostgreSQL instead of a new release
* that has removed the option; put %_ back into the escape string
* set */
/* XXX: manipulate that string here */
}
Make sense?
Bearing in mind that I've never programmed the PostgreSQL C API, so I
could well be missing something very obvious to someone who has; anyone
reading this, please assume that something obvious was not elided
because it was obvious but because I don't know enough, so you should
speak up!
-Phil
