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
