From: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: COPY formatting |
Date: | 2004-03-19 14:52:14 |
Message-ID: | 20040319145214.GA9495@zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 19, 2004 at 09:39:58AM -0500, Tom Lane wrote:
> Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> writes:
> >>> It's pity that main idea of current COPY is based on separated lines
> >>> and it is not more common interface for streaming data between FE and BE.
> >>
> >> Yeah, that was another concern I had. This API would let the formatter
> >> control line-level layout but it would not eliminate the hard-wired
> >> significance of newline. What's worse, there isn't any clean way to
> >> deal with reading quoted newlines --- the formatter can't really replace
> >> the default quoting rules if the low-level code is going to decide
> >> whether a newline is quoted or not.
>
> > I think latest protocol version works with blocks of data and no with
> > lines and client PQputCopyData() returns a block -- only docs says that
> > it is row of table.
>
> But you can't assume that the client will send blocks that are
> semantically significant. For instance, if psql is reading a file to
> send with \copy, how's it going to know how the file is formatted?
And what \n in attibutes data in CSV? I think CSV format doesn't use
some escape for newline char. It means psql with \copy cannot be sure
with CSV.
Karel
--
Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
http://home.zf.jcu.cz/~zakkr/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-03-19 14:54:37 | Re: COPY formatting |
Previous Message | Fernando Nasser | 2004-03-19 14:49:23 | Re: COPY formatting |