Re: [BUGS] BUG #4027: backslash escaping not disabled inplpgsql

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: [BUGS] BUG #4027: backslash escaping not disabled inplpgsql
Дата
Msg-id 49DDCFA7.EE98.0025.0@wicourts.gov
обсуждение исходный текст
Ответ на Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Re: [BUGS] BUG #4027: backslash escaping not disabled inplpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Bruce Momjian <bruce@momjian.us> 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_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 option?:
SET configuration_parameter { TO value | = value | FROM CURRENT }
I would like to see standard character string literals at least
available in PL/pgSQL, although I don't personally care whether it is
the default or whether I need to specify it with the above option. 
Might it not confuse people to have this GUC behave differently than
others, though?
-Kevin


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re: [BUGS] BUG #4027: backslash escaping not disabled inplpgsql