Re: [HACKERS] backslash in psql output

Bruce Momjian <maillist@candle.pha.pa.us> writes:
> 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.

Well, actually there *was* public discussion of this issue, on the
pgsql-interfaces list around 12/13 August.  The consensus was that
unnecessary backslashing was a bad idea --- in fact, I didn't see
*anyone* arguing in favor of the old behavior, and the people who
actually had backslashes in their data definitely didn't want it.
Admittedly it was a pretty small sample (Tom Lockhart and I were
two of the primary complainers) but there wasn't any sentiment
for keeping the old behavior.

Keep in mind that what we are discussing here is the behavior of
PQprint(), not the behavior of FE/BE transport protocol or anything
else that affects data received by applications.  PQprint's goal in
life is to present data in a reasonably human-friendly way, *not*
to produce a completely unambiguous machine-readable syntax.  Its
output format is in fact very ambiguous.  Here's an example:

play=> create table test(id int4, val text);
play=> insert into test values (1, NULL);
play=> insert into test values (2, '    ');
play=> insert into test values (3, 'foobar');
play=> insert into test values (4, 'oneback\\slash');
play=> insert into test values (5, 'onevert|bar');
play=> select * from test;
id|val
--+-------------
 1|
 2|
 3|foobar
 4|oneback\slash
 5|onevert|bar
(5 rows)

You can't tell the difference between a NULL field and an all-blanks
value in this format; nor can you really be sure how many trailing
blanks there are in tuples 3 and 5.  So the goal is readability,
not lack of ambiguity.  Given that goal, I don't see the value of
printing backslash escapes.  Are you really having difficulty telling
the data vertical bar from the ones used as column separators?
Physical alignment is the cue the eye relies on, I think.

The only cases that PQprint inserted backslashes for were the column
separator char (unnecessary per above example), newlines (also not
exactly hard to recognize), and backslash itself.  All of these
seem unnecessary and confusing to me.

I'm sorry that this change sat in my to-do queue for so long, but
I don't see it as a last-minute thing.  The consensus to do it was
established two months ago.

            regards, tom lane