Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql
Дата
Msg-id 200904101942.n3AJgb721606@momjian.us
обсуждение исходный текст
Ответ на Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Re: [BUGS] BUG #4027: backslash escapingnotdisabled inplpgsql  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
Tom Lane wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> > 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?
> 
> Right, because the behavior wouldn't actually change.
> 
> I'm starting to lean in the same direction --- the current plpgsql
> behavior with the GUC 'on' is sufficiently broken that it seems unlikely
> anyone is doing much with plpgsql and that setting.
> 
> It still remains that actually flipping the default would probably
> provoke lots of breakage, but plpgsql's current behavior doesn't
> help that.

It would be nice to know if we are ever going to set
standard_conforming_strings to on.  If not, we can remove the TODO item.
The bigger question is if we aren't going to turn it on was there any
value to setting escape_string_warning to on in 8.2?  We required a lot
of users to prefix their strings with 'E'.

--  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 по дате отправления:

Предыдущее
От: "Dann Corbit"
Дата:
Сообщение: Re: Windows installation service
Следующее
От: Richard Rowell
Дата:
Сообщение: Re: A renewed plea for inclusion of zone.tab