Here are a few more questions to throw out.
1. There's a comment in AbstractJdbc1Connection saying "TODO: handle
transaction status". Did someone have something specific in mind regarding
how transaction status was to be "handled"?
2. What's the oldest pgsql version that we intend to support with the drivers
in 7.4? Is it 7.0? 6.x?
3. For someone who knows the v3 protocol; there are a number of cases where
multiple queries are issued by one statement in the driver. My understanding
is that this is not allowed in extended query. Does that mean that we're
stuck with multiple round-trips if we substitute extended query? Or may I
send multiple consecutive parse, bind, and execute commands without an
intervening read of the result; and then read all the results at once?
This latter bit seems to me like it risks walking into a trap where I'm
blocked on my send buffer waiting for the server to read more of a statement,
and the server is blocked on its send buffer waiting for me to read the
results from a previous execute. But basically, I'm thinking there has to be
a way in v3 extended query to avoid this problem; otherwise, it would be a
potentially serious performance issue with no solution. Is there a way?
4. As I plan the changes I'd like to make for v3 protocol support, it's
starting to look tempting to segregate a good bit of the code into separate
classes for v2 and v3. Thus, we'd have:
V2QueryExecutor - For v2 code
V3QueryExecutor - For v3 code
QueryExecutorUtil - For code shared between both classes above
and the same for AbstractJdbc*Statement and AbstractJdbc*ResultSet. Would
this meet with objections if I tried to get this incorporated into the actual
drivers?
--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
