John Lister wrote:
> Oliver Jowett wrote
>> John Lister wrote:
>>
>>> Hi, i was wondering if there is any reason why the query preparation is
>>> done when the query is executed instead of when the preparedStatement is
>>> created.
>>>
>>
>> It would be an extra network round-trip on every query, and there's no
>> requirement to prepare it early.
>>
>>
> I'm not sure why it would be there would be an extra round trip? The
> parse is done anyway, the only extra round trip would be if you did a
> describe (which admittedly i'm looking into optionally doing for binary
> transfers) or if you didn't use the preparedStatement to do any queries
> which is i'd imagine is rare.
>
> Maybe i've missed something?
You presumably want to wait for the result of Parse before returning
from prepareStatement() if you are doing preparation at that point.
Otherwise I don't quite see the point? And that's where the extra
round-trip is.
There are also another couple of hurdles to doing preparation earlier:
1) use of the unnamed statement would become impossible
2) at the time of prepareStatement, you don't have parameter type
information, which is needed by Parse.
(2) seems to be a showstopper to me.
>> Why would you want to move it?
>>
> To me it would be cleaner
I don't think it would be much cleaner, if at all. Are there any other
reasons for moving it, other than implementation reasons?
> Also, with regard to extra network traffic and latency i'm not suggesting changing the way normal statements are
used,only PreparedStatements. This to me fits in more with the way the JDBC spec is worded and i'd guess the more usual
usecase of statements - Statement for quick and dirty one off queries, PreparedStatement for more complicated/multiple
usequeries.
A common use of PreparedStatements is for safe parameter interpolation.
I very rarely use plain statements in my own code for this reason, even
for one-shot queries. No point in writing yet another SQL string escaper
when the driver already deals with it ..
-O