Hi again.
2007/5/31, Dave Cramer <pg@fastcrypt.com>:
> I think you have to make it an extension somehow. I'd leave
> getCopyAPI in place, I think the harder part is getting the protocol
> to work,
I found these hooks for protocol level implementation at end of
org.postgresql.core.v3.QueryExecutorImpl.processResults():
case 'G': // CopyInResponse
case 'H': // CopyOutResponse
case 'c': // CopyDone
case 'd': // CopyData
{
// COPY FROM STDIN / COPY TO STDOUT, neither of
which are currently
// supported.
...
handler.handleError(new PSQLException(GT.tr("The
driver currently does not support COPY operations."),
PSQLState.NOT_IMPLEMENTED));
}
break;
AFAIK (counting out breaking current design) the only way to implement
this at protocol level without touching core.v3 would be to clone the
whole package with every class inherited from core.v3, and copy
contents of QueryExecutorImpl there. I'd rather not.
Problem is that class has its stuff (pgStream) declared as private, so
I can't just inherit a class to override that single method.
Furthermore, I'd end up duplicating the protocol support implemented
in original version of that method. Thus, I'll edit it in place. Even
if it ends up in a rejected patch at least the patch gets it right.
The protocol spec is clear enough by itself.
I'll still have to look how to best pass the CopyData rows between BE
and application. They could probably be encapsulated as tuples, but
I'll have to read a bit more to find out the best way.
I won't handle field types (text/binary in the protocol level) because
I'm looking forward to a solution where I could pass whole or possibly
even multiple rows as raw(ish) byte[] at once. If this becomes a
barrier for acceptance I can reconsider.
Thanks for the clear source. It is what makes enhancements such as
this possible on short notice.
So no commits this week, but there's still hoping I'll get something out.
--
Kalle Hallivuori +358-41-5053073 http://korpiq.iki.fi/
