| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Jonathan Guthrie <jguthrie(at)brokersys(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Re: [BUGS] BUG #4027: backslash escaping not disabled inplpgsql |
| Date: | 2009-04-09 16:55:16 |
| Message-ID: | 27053.1239296116@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> 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
> standard_conforming_strings control PL/pgSQL behavior; this is what we
> did with SQL and it seems to have worked.
Well, considering that we are still afraid to pull the trigger on
changing the standard_conforming_strings default, it's a bit premature
to claim that it "worked" for SQL. But I agree that some kind of
stepwise process will be necessary if we want to try to change this.
IIRC there was some discussion of using plpgsql's (undocumented) #option
syntax to control this, rather than having a GUC that would be specific
to plpgsql.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-04-09 16:59:28 | Re: possible bug not in open items |
| Previous Message | Bruce Momjian | 2009-04-09 16:54:27 | Re: BUG #4738: Cannot reconnect to shared memory |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Gierth | 2009-04-09 16:55:24 | Re: hstore patch, part 2 |
| Previous Message | Bruce Momjian | 2009-04-09 16:33:24 | Re: hstore patch, part 2 |