From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] backslash in psql output |
Date: | 1998-10-11 01:45:50 |
Message-ID: | 199810110145.VAA01988@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
OK, I understand your point here, that we must maximize readability, and
that robustness is not as important.
OK, let's keep the removal of backslashes. Can you recommend a nice
NULL display, perhaps '[NULL]' or '<NULL>'?
--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-10-11 01:51:26 | Re: [HACKERS] select * from ..;vacuum crashes |
Previous Message | Bruce Momjian | 1998-10-11 01:35:47 | Re: [HACKERS] postmaster locking issues. |