Re: FYI: porting Copy API to 8.x
От | Kris Jurka |
---|---|
Тема | Re: FYI: porting Copy API to 8.x |
Дата | |
Msg-id | Pine.BSO.4.64.0706130400400.12996@leary.csoft.net обсуждение исходный текст |
Ответ на | Re: FYI: porting Copy API to 8.x ("Kalle Hallivuori" <kato@iki.fi>) |
Ответы |
Re: FYI: porting Copy API to 8.x
|
Список | 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 по дате отправления: