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. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
