Bruce Momjian <email@example.com> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq