Re: COPY formatting

Karel Zak <zakkr@zf.jcu.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?
It's just gonna send disk-block-sized messages, and the backend has to
discover the semantic boundaries for itself.

>  It sounds good, but I think we  both not full sure about it now, right?
>  CSV support will probably better add by DELIMITER extension.

Yeah, without people beating on our door for such a hook, it seems like
Andrew's DELIMITER idea is the best thing to do for now.
        regards, tom lane