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: olly(at)lfix(dot)co(dot)uk (Oliver Elphick)
Cc: lockhart(at)alumni(dot)caltech(dot)edu, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] backslash in psql output
Date: 1998-10-10 15:02:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Bruce Momjian wrote:
>   >> > now the format will be ambigious.
>   >> >         test=> insert into test3 values ('\\x');
>   >> >         test=> select * from test3;
>   >> >         --
>   >> >         \x
>   >> > This used to show as:
>   >> >         --
>   >> >         \\x
>   >> > Comments?
>   >>...
>   >But what about backward compatability?  Aren't there people expecting
>   >psql output to show double backslashes?  What do we do to display pipes
>   >in the output?
> That change seems a good thing: the front-end ought to display what the
> user wants.  Any manipulations should be done behind the scenes.  If I
> store a DOS pathname, I don't want to see the backslashes doubled in it.
> Even worse, I don't want to see them eliminated altogether, which is what
> happens now if I don't remember to double them on input.
> You mentioned that psql backslash-escapes the column delimiter character.
> I think that this behaviour ought to be removed as well; it should be obvious
> from the alignment with headings and other lines whether a pipe character is
> part of the data or a column delimiter.  If it really matters, a user
> can specify another character to use as delimiter. 

If the user is reading psql output into a program, it is very unclear
how to determine a valid column delimiter vs. a delimiter in the data. 
Yes, they can change delimiters, but they person has to choose one that
would never appear in the data stream, and that is sometimes impossible.

I don't know how many people do this type of thing, but I think we have
to ask the general users.

> An unsophisticated user expects to type characters and have them
> accepted; he should not have to know that certain characters need to be
> doubled or escaped, nor that certain characters he sees in the output are
> to be ignored.

If we don't require double backslashes on input, we can no longer accept
C escape sequences like \r or \n, or octal values.  As it is now, octal
values are now interpreted, instead of returning their values:

	test=> insert into test3 values ('\253');
	INSERT 323237 1
	test=> select * from test3;
	(3 rows)

I don't know if it always did this or not.

I can understand people wanting to change things, but we have to discuss
all the issues.

And what about the COPY command.  Do you want to change the display of
escape characters there too?  I hope not.

  Bruce Momjian                        |
  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

pgsql-hackers by date

Next:From: Tom LaneDate: 1998-10-10 15:19:44
Subject: Re: [HACKERS] backslash in psql output
Previous:From: D'Arcy J.M. CainDate: 1998-10-10 13:58:08
Subject: Re: [HACKERS] CIDR type and functions

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