Brendan Jurd wrote:
> On Sat, Apr 11, 2009 at 4:40 AM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
> > The aspect of 8.3 behavior that concerns me most is that neither the
> > author of a function, nor anyone using it, can control or predict
> > which way a string literal with a backslash will be interpreted,
> > unless the author explicitly specifies the SET
> > standard_conforming_strings clause in the function declaration. ?I'm
> > betting that most people writing and using plpgsql functions don't
> > know that. ?Any thoughts about what can or should be done about that?
>
> Isn't this exactly the same problem that application authors have been
> facing with SQL in their code?
>
> Namely, if there's a backslash anywhere in a string literal you
> *cannot* leave it as a bare single-quoted string literal. You need to
> decide whether you want the backslash treated as an escape character
> (and therefore use E quoting), or as a backslash (and therefore use $$
> quoting).
>
> Until you've done that for every single string literal with a
> backslash, your application isn't ready for
> standard_conforming_strings to be switched on.
>
> I agree that there are probably a great many app authors out there who
> don't realise how very boned they might be if the default GUC gets
> changed and they haven't prepared their SQL to cope.
I assume those authors are getting warnings, which is something we don't
for PL/pgSQL now.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +