Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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.
I'm not convinced. Wouldn't it be better if psql commands track the
backend syntax? With standard_conforming_strings on, there will be two
ways to tell COPY you want a tab as a delimiter:
DELIMITER '<actual tab char>'
DELIMITER E'\t'
and in particular this will NOT do that:
DELIMITER '\t'
If we keep '\t' as meaning tab in the \copy syntax then I think we're
going to cause confusion in the long run. I think we should fix \copy
and related psql backslash commands to accept E'\t', and make sure that
the behavior is the same as the connected backend depending on what its
standard_conforming_strings setting is.
There is a secondary, largely cosmetic question of whether psql should
attempt to prevent you from seeing escape_string_warning messages.
I personally have come to the conclusion that escape_string_warning is
probably not going to be on by default anyway ;-), and hence it's not
worth going to great extremes to prevent this, particularly if it breaks
the ability to use psql against pre-8.1 servers.
regards, tom lane
