Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > The attached patch fixes the warning you received by adding E'' strings
> > to the \copy arguments, and adds it for the other backslash commands
> > like \d.
>
> You missed the point entirely Bruce. The problem is that \copy's
> argument parsing won't accept an option specified as E'\t' --- I believe
> it is seeing that as two arguments instead of one.
Right. I think the question is whether we want all psql strings to
accept backslashes, and hence not support E'' at all for psql commands.
I figured that made the most sense.
> The patch you propose addresses a completely different issue, which is
> whether we are going to E-ify all our utilities so they don't trigger
> the escape_string_warning patch. I don't think that that is the right
> direction to go in. In fact, based on what I was doing this afternoon,
> my feeling is that 8.2 will not ship with escape_string_warning turned
> on by default. It's a good tool for testing code when you're trying to
> move the code over to standard conforming strings, but it's just too
> noisy for code that in point of fact is already fixed.
Well, we can remove the change I made to ruleutils.c::get_const_expr()
because you are right, we are setting standard_conforming_strings in
pg_dump, so we know the value and E'' is not necessary. We might also
want to turn off escape_string_warning in pg_dump as well.
As far as psql, we could check standard_conforming_strings and just use
the proper escaping without using E'', assuming escape_string_warning
is off.
escape_string_warning was really designed as a portability tool, so if
we don't want to use it for our utilities, that is fine, as long as we
are checking standard_conforming_strings.
If we don't set escape_string_warning on for a release, will we be able
to turn on standard_conforming_strings? I just don't know.
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
