From: | Kris Jurka <books(at)ejurka(dot)com> |
---|---|
To: | Kalle Hallivuori <kato(at)iki(dot)fi> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: FYI: porting Copy API to 8.x |
Date: | 2007-06-13 08:16:35 |
Message-ID: | Pine.BSO.4.64.0706130400400.12996@leary.csoft.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Kalle Hallivuori | 2007-06-13 13:26:38 | Re: FYI: porting Copy API to 8.x |
Previous Message | Kris Jurka | 2007-06-13 07:27:53 | Re: Error reporting issue in SimpleParameterList |