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.
> > Also are there plans to support other elements of the COPY syntax? For
> > example NULL AS, OIDS, and column lists.
>
> Yes. My current thinking is to provide a method that takes an arbitrary
> COPY command. This also gives us backwards compatibility since the command
> syntax has changed from 7.2 to 7.3.
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.
Kris Jurka
