Re: patch for COPY

On Sun, 9 Feb 2003, Kris Jurka wrote:
>
> On Sat, 8 Feb 2003, Michael Adler wrote:
> >
> > On Fri, 7 Feb 2003, Kris Jurka wrote:
> > > One of the failings of the copy protocol is that on error basically the
> > > connection is hosed. Is it possible to reset the connection state on
> > > error for the user?
> >
> > Assuming the rest of the driver can support this behavior, I'm guess that
> > we should make this optional.
>
> That's the question. Can we reset the driver to a close enough state that
> it is transparent to the user. With normal JDBC access the user will
> expect to get an SQLException call connection.rollback() and continue as
> usual. This could be tricky.
>

If we take libpq as the standard for what's practical to acheive with the
FE/BE protocol, I don't think we'll be able to maintain much. libpq simply
closes and opens the connection. (following test with a 7.2 installation)

testdb=# set datestyle to German;
SET VARIABLE
testdb=# show datestyle;
NOTICE: DateStyle is German with European conventions
SHOW VARIABLE
testdb=# \i isf
psql:isf:1: ERROR: copy: line 1, pg_atoi: error in "T": can't parse "T"
psql:isf:1: lost synchronization with server, resetting connection
testdb=#
testdb=# show datestyle;
NOTICE: DateStyle is ISO with US (NonEuropean) conventions
SHOW VARIABLE

I wonder if the best we can do is to establish a fresh connection and
begin a transaction. If they call rollback, it will rollback nothing, but
at least it behaves outwardly in a uniform fashion.

> What is the expected use case for a copyIn? Is an InputStream a
> reasonable means for input. Would defining a CopyInputSource interface
> for a user's class to implement be useful? The JDBC driver could then
> pull data directly from the user's representation without an intermediate
> persistance to the InputStream.

For my needs, an InputStream is reasonable.

FileInputStream fis = new FileInputStream("dumpfile");
copyIn("destination_table", fis);

Whether someone else finds that insufficient is another matter.

Personally, I think that eschewing java.io would increase the complexity
of the driver without a demonstrated need for the functionality. It's
likely that I lack the imagination to see how useful such a feature would
be. I will leave the decision to someone with more experience on this
project.

If a user has particular needs and is concerned with memory footprint, I
would recommend the Piped(Input/Output)Streams.

Mike Adler