Brendan Jurd wrote: > On Sat, Apr 11, 2009 at 4:40 AM, Kevin Grittner > <kevin.gritt...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
