From: | James Robinson <jlrobins(at)socialserve(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Under what circumstances does PreparedStatement use stored plans? |
Date: | 2004-04-14 03:54:44 |
Message-ID: | 776B197A-8DC7-11D8-9B18-000A9566A412@socialserve.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2004-04-14 06:04:31 | Re: patch: fix TimeTest in timezones ahead of GMT |
Previous Message | Tom Lane | 2004-04-14 03:40:40 | Re: Under what circumstances does PreparedStatement use stored plans? |