Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >> 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. > > Yeah. This is one reason why I'm still afraid to flip the default > value of standard_conforming_strings --- there seems too much risk > of widespread breakage. > > I don't have a good solution for it, but I agree it's a problem. Now that I see that string literals are currently interpreted inconsistently, I don't think there's any way to get to a sane behavior without risking some breakage somewhere. If, as I've seen some people assert, most people aren't setting the standard_conforming_strings = on, it would seem to be reasonable to put the risk with that 'on' setting. Let me ask this -- If we were to change the plpgsql parser to pay attention to the GUC, it couldn't break anything for any environment which always has the GUC 'off', could it? If not, I am having a hard time seeing a smoother transition than to change the plpgsql parser to use the GUC, and to have the CREATE FUNCTION statement make a special case of defaulting this GUC to FROM CURRENT. Making an exception of this offends a little, but not as badly as unpredictable runtime behavior. An advantage of this approach is that it would be just another place to check your string literals when and if you go to switch over to standard literals. Whether to ever change the default behavior over to the standard is more of a "marketing" decision than a technical one, I think. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
