Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>, Jonathan Guthrie <jguthrie@brokersys.com>, Peter Eisentraut <peter_e@gmx.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2009-04-10T19:42:37Z
Lists: pgsql-bugs, 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. +