Bruce Momjian writes:
> Tom Lane wrote:
>> It can be, the question is whether we're prepared to break everything
>> under the sun until people add that.
> I think we would first have to agree to issue escape_string_warning
> warnings for code in PL/pgSQL functions, then think about having
> stand
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Can't that be managed with this CREATE FUNCTION option?:
>> SET configuration_parameter { TO value | = value | FROM CURRENT }
>
> It can be, the question is whether we're prepared to break
everything
> under the sun until people add that.
Well, su
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Bruce Momjian wrote:
> >> I think the big issue is that having standard_conforming_strings
> >> affect function behavior introduces the same problems we have had in
> >> the past of having a GUC affect function behavior.
>
> > Can't that be managed
"Kevin Grittner" writes:
> Bruce Momjian wrote:
>> I think the big issue is that having standard_conforming_strings
>> affect function behavior introduces the same problems we have had in
>> the past of having a GUC affect function behavior.
> Can't that be managed with this CREATE FUNCTION opt
Bruce Momjian wrote:
> standard_conforming_strings was added in Postgres 8.1, and
> escape_string_warning was enabled in 8.2.
Other way around -- the warning was available in 8.1; the standard
character string literals were available in 8.2.
> I think the big issue is that having standard_confo
