Skip site navigation (1) Skip section navigation (2)

Re: FYI: porting Copy API to 8.x

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: (view raw, whole thread or download thread mbox)
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

In response to


pgsql-jdbc by date

Next:From: Kalle HallivuoriDate: 2007-06-13 13:26:38
Subject: Re: FYI: porting Copy API to 8.x
Previous:From: Kris JurkaDate: 2007-06-13 07:27:53
Subject: Re: Error reporting issue in SimpleParameterList

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group