Hi Dave!
2007/5/30, Dave Cramer <pg@fastcrypt.com>:
> The reason that the patch has never been officially accepted is
> because it creates two protocol paths.
>
> To do this correctly you need to add the copy functionality into the
> current protocol handler as opposed to having a separate protocol
> handler for copy.
Thanks, now I understand why it's not there. I can take a look at
alternative approaches tomorrow, and only go with the ugly one if I
don't come up with an (moderately easily implementable) acceptable
design.
Is it more of an open design problem that many people have looked
closely into, or rather just a matter of someone getting to it? Ie. is
it likely there is no clean way to add these special cases inside the
protocol handler?
As for redesign, which would be the least abhorred way of providing
the functionality for use:
1. Separate Copy API available via a getCopyAPI() method in PGConnection API?
2. Separate Copy API available with some cleaner approach, which?
3. Special Copy methods in PGConnection API?
4. Special cases to batch processing (FROM STDIN) and resultset
collecting (TO STDOUT)?
5. Special cases to some other part of the standard JDBC API, which?
Cheers,
--
Kalle Hallivuori +358-41-5053073 http://korpiq.iki.fi/
