> We can include a command-line option to re-enable the escapes. Anyone
> can use that form, and can define an alias for it if they need.
>
> I understand your concern about backward compatibility, but imho the
> convention it was using makes things more confusing, especially for a
> new user. I'm not certain (assuming things have changed recently) that
> the new behavior is what I would want, but the old behavior was not one
> I would have guessed at.
>
> Using psql to pipe output to another program is the best example of why
> one might _not_ want to re-escape the strings. If the goal is to use
> data from the database, then that data is what you will want to see in
> the pipe.
>
> Anyway, in the long run I'd like to consider moving toward a "no-escape"
> default output for psql. If you think that it is too short notice to
> fully understand the ramifications of a change this close to release, or
> if your "faithful correspondents" have cottage cheese for brains, then
> go ahead and revert it ;) But I like the new behavior in principle...
>
> - Tom
>
> Another possibility is to make it a configuration option:
>
> ./configure --enable-psql-string-escapes
>
> or something like that...
>
I realize the double-backslash is confusing, but I don't think we can
make such a user-visible change at this time. I think we need to open
discussion on this issue on the general list, and to include discussion
of NULL displays, and any other issues, as well as how to properly
output the column separation character if that appears in the data.
So, I think we have to put it back to the old way, and open discussion
about this after 6.4.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026