Re: A few more questions

Chris,

Chris Smith wrote:
> 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"?

Well in general someone could include a transaction control statement
(begin, commit, rollback) in a sql statement. This would confuse the
driver since it is assuming that it is controlling transaction state as
a result of the current setting of autoCommit(). The transaction state
reported by the server would allow the driver to verify that the state
was what the driver expected and allow the driver to correct it if it
wasn't (for example if autoCommit() was false and the user issued a
commit, then the driver would detect that fact that the transaction had
ended and start a new one).

>
> 2. What's the oldest pgsql version that we intend to support with the drivers
> in 7.4? Is it 7.0? 6.x?

In the past when this has been discussed on the mail lists we decided to
support two past releases. Thus the 7.4 driver would support back to
7.2. However we have also never removed code that enables older
versions than that. So one could say we support two versions back, but
expect older versions to generally work, but we wouldn't consider it a
bug if they didn't. I am fine with actually beginning to remove the
older support, but we really should then document the policy on the web
site and in the documentation.

>
> 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?
>

Which examples of multiple statements are you referring to? As I see
it, many of the multiple statements in a single query are there because
of the limitations of the V2 protocol, but under the V3 protocol they
can be eliminated by using the features of the V3 protocol. So which
ones are you looking at that you feel are a problem? I am sure there
are some and I think Oliver has already responded with good ideas on how
to handle those cases, but in general, I think we should be trying to
eliminate them were possible.

> 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
>

Breaking this code out would be a very good idea.

> 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?

The AbstractJdbc* stuff is much more tricky. But I think from later
emails in this thread you understand the issues and are on the right track.

thanks,
--Barry