Re: [HACKERS] backslash in psql output - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: [HACKERS] backslash in psql output |
Date | |
Msg-id | 199810101502.LAA24390@candle.pha.pa.us Whole thread Raw |
In response to | Re: [HACKERS] backslash in psql output ("Oliver Elphick" <olly@lfix.co.uk>) |
Responses |
Re: [HACKERS] backslash in psql output
Re: [HACKERS] backslash in psql output |
List | 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; x -------- nedd � � (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 | 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
pgsql-hackers by date: