Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] backslash in psql output

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 (view raw or flat)
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


In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-10-11 01:51:26
Subject: Re: [HACKERS] select * from ..;vacuum crashes
Previous:From: Bruce MomjianDate: 1998-10-11 01:35:47
Subject: Re: [HACKERS] postmaster locking issues.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group