| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | olly(at)lfix(dot)co(dot)uk (Oliver Elphick), lockhart(at)alumni(dot)caltech(dot)edu, hackers(at)postgreSQL(dot)org |
| Subject: | Re: [HACKERS] backslash in psql output |
| Date: | 1998-10-10 22:36:10 |
| Message-ID: | 25962.908058970@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> 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.
Quite true, but the PQprint output format has never been
program-friendly, as I pointed out previously.
I think the appropriate response to this gripe is to add another
command-line switch to psql, which would change its display of SELECT
data to something more suitable for program consumption, rather than
trying to make a single output format that's a bad compromise between
human readability and machine readability.
Perhaps the COPY data syntax would work for a program-friendly output
format? (Basically tabs and newlines are field and row delimiters,
with (IIRC) backslash-escaping of tabs, newlines, backslash itself,
and maybe nulls and suchlike. Also \N stands for a null field.)
> And what about the COPY command. Do you want to change the display of
> escape characters there too? I hope not.
I wasn't proposing any such thing, unless it proves necessary to ensure
we can copy arbitrary-8-bit text data out and back in. But that's a
task for a future release.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Billy G. Allie | 1998-10-11 00:27:06 | PostgreSQL 6.4 patches - portability related. |
| Previous Message | Gene Selkov, Jr. | 1998-10-10 22:17:36 | yet another problem in recent builds, GIST this time |