Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@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
