Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql
От | Bruce Momjian |
---|---|
Тема | Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql |
Дата | |
Msg-id | 200904091516.n39FGjJ26276@momjian.us обсуждение исходный текст |
Ответы |
Re: Re: [BUGS] BUG #4027: backslash escaping not disabled
in plpgsql
Re: [BUGS] BUG #4027: backslash escaping not disabled inplpgsql |
Список | pgsql-hackers |
Peter Eisentraut wrote: > Tom Lane wrote: > > plpgsql does not consider standard_conforming_strings --- it still uses > > backslash escaping in its function bodies regardless. Since the > > language itself is not standardized, I see no particular reason that > > standard_conforming_strings should govern it. > > I think plpgsql should behave either consistently with the rest of PostgreSQL > or with Oracle, which it is copied from. > > > I believe the reason for > > not changing it was that it seemed too likely to break existing > > functions, with potentially nasty consequences if they chanced to be > > security definers. > > Is this actually true or did we just forget it? :-) I have added this TODO item: Consider honoring standard_conforming_strings in PL/pgSQL functionbodies * http://archives.postgresql.org/pgsql-bugs/2008-03/msg00102.php Are we every going to enable standard_conforming_strings by default? If not, I will remove the TODO item mentiong this. standard_conforming_strings was added in Postgres 8.1, and escape_string_warning was enabled 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. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: