Re: Under what circumstances does PreparedStatement use stored plans?
От | James Robinson |
---|---|
Тема | Re: Under what circumstances does PreparedStatement use stored plans? |
Дата | |
Msg-id | 776B197A-8DC7-11D8-9B18-000A9566A412@socialserve.com обсуждение исходный текст |
Ответ на | Re: Under what circumstances does PreparedStatement use stored plans? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-jdbc |
>> > > I didn't say it was easy ;-) ... when we were designing this last year, > Dave gave me to understand that actually using it will take some pretty > significant revisions in the JDBC driver. But the way forward is open, > as far as I know. > > regards, tom lane > I've made it through giving a thorough reading of the v3 messages Parse, Bind, and Execute, and it does indeed look like things were planned out enough to map relatively cleanly onto the variations required by a full JDBC implementation (at least the cursor- based fetching and/or prepared queries -- You don't want to know about updateable result sets, do you :-). Looks like the existing driver 'shells out' to SQL commands in these places, needing to be replaced with lower-level raw protocol commands (assuming a v3-capable backend, OC). Not naively done, but also not uber-hacker material either. Not sure if I'm stepping up to the task (right away) -- looks like I can get my hack-cache done first, assuming that PreparedStatement should just 'work', and if it doesn't, then it could be corrected in parallel or after the fact. Anything else looks fun relative to EJB / web-application code. ---- James Robinson Socialserve.com
В списке pgsql-jdbc по дате отправления: