Re: FYI: porting Copy API to 8.x - Mailing list pgsql-jdbc

From Kris Jurka
Subject Re: FYI: porting Copy API to 8.x
Date
Msg-id Pine.BSO.4.64.0706130400400.12996@leary.csoft.net
Whole thread Raw
In response to Re: FYI: porting Copy API to 8.x  ("Kalle Hallivuori" <kato@iki.fi>)
Responses Re: FYI: porting Copy API to 8.x  ("Kalle Hallivuori" <kato@iki.fi>)
List pgsql-jdbc

On Mon, 11 Jun 2007, Kalle Hallivuori wrote:

> Attached is a patch against postgresql-jdbc-8.2-505.src containing
> Copy support inside v3/QueryExecutorImpl usable through a separate API
> together with minimal unit tests and documentation.
>

This patch doesn't apply cleanly because there's a mix of unix and windows
EOL characters and it seems to have some other application problems.

The API is not thread safe.  If two threads are using the same connection
the synchronization in QueryExecutorImpl prevents them from stepping on
each others toes and writing garbage to the backend.  So the call to
QueryExecutor must be an atomic operation and implies that the
QueryExecutorImpl will be the controller and demand/push data from some
kind of copy client instead of the other way around.

Also I'm not especially fond of the row based API that you've come up
with.  It seems like you should either go to an element or stream based
API.  Who has a premade row?  They've either got single fields or a bulk
stream.  Consider someone with a CSV file on their client machine that
they want to copy to the server, they'd have to parse it to break it into
rows which can be tricky with embedded newlines.  They'd like an easy way
to just dump it to the server and let it deal with it.

Kris Jurka

pgsql-jdbc by date:

Previous
From: Thomas Burdairon
Date:
Subject: Re: Using INET types in prepared statements in Java?
Next
From: "Kalle Hallivuori"
Date:
Subject: Re: FYI: porting Copy API to 8.x