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. +

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org

Reply via email to