Re: COPY formatting

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/

In response to

Responses

Browse pgsql-hackers by date

  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