Kris Jurka wrote:
> Yes, the current copy patches only support *Stream which does leave the
> user exposed to encoding issues. Providing a Reader/Writer API doesn't
> support COPY ... BINARY, but I don't know how many people would actually
> use such a thing. Parallel interfaces are a possibility, but I'd guess
> people would end up using the Stream versions for non-binary data anyway.
>
> Does anyone have the need to do COPY BINARY?
I have never felt the temptation.
As far as I understand, that would mean that your code is dependent
on the endianness of the server machine and compile time flags like
--enable-integer-datetime.
> I also wonder what the encoding conversion hit is if no conversion needs
> to be done. Perhaps we should measure that before abandonding the Stream
> API?
That would certainly be interesting, although I don't think it's a killer
argument.
I don't want to go on about Java, but I guess that if you need to load
huge amounts of data into a database as fast as possible, you would probably
not do this via JDBC from a remote machine, but use psql locally on the server.
So performance is of course important, but not the most important thing for me
when I code Java.
For me the nice thing about COPY support in JDBC would be that you have
an easy way to load CSV files into the database or dump them out from a
database, which is a requirement I encounter frequently.
Yours,
Laurenz Albe
