Bruce Momjian <bruce@momjian.us> writes:
> Kevin Grittner wrote:
>> My personal bias is to go to the standard behavior as the default at
>> some point. For legacy reasons, I don't know that you would ever want
>> to remove the setting; especially since I don't think it adds much
>> code if you're going to support the E'...' literals. The ugliest
>> thing about this GUC is that it adds some complications to the flex
>> code, but it doesn't seem that bad to me.
> Agreed, we would probably never remove standard_conforming_strings.
Yeah, I don't see that happening either. I agree with Kevin that it
would be nice to flip the default at some point, but I'm afraid it's a
long way off yet.
Back to the point at hand: do we want to look at making plpgsql respect
the GUC? I think it's a bit trickier than it looks, because we don't
want duplicate warnings from both plpgsql and the main parser for
strings that get fed through. I'm inclined to deal with the special
case (RAISE and anything else similar) by changing the code so that we
*do* feed the string literal through the main parser, not for any
functional effect but just to have it throw the right warnings/errors.
Otherwise the plpgsql lexer has to somehow know when to warn and when
not, which'd be a mess.
regards, tom lane
