Re: A few more questions - Mailing list pgsql-jdbc
From | Barry Lind |
---|---|
Subject | Re: A few more questions |
Date | |
Msg-id | 402EEBAE.2030006@xythos.com Whole thread Raw |
In response to | A few more questions ("Chris Smith" <chris@mindiq.com>) |
List | pgsql-jdbc |
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
pgsql-jdbc by date: