On Sun, 14 Apr 2002, Barry Lind wrote:
> But since the syntax for prepare is: PREPARE <name> AS <statement> you
> can't easily reuse sql prepared by other PreparedStatement objects since
> you don't know if the sql you are about to execute has or has not yet
> been prepared or what <name> was used in that prepare. Thus you will
> always need to do a new prepare. (This only is true if the driver is
> trying to automatically use PREPARE/EXECUTE, which was the senario I was
> talking about).
Well, there are some ugly tricks you could build into the driver
to allow it to effectively use a PREPAREd statement with multiple,
identical PreparedStatement objects (basically, via the driver
caching various things and identifying PreparedStatements created
with the same SQL), but it's messy enough and has some problems
hard enough to resolve that I can't actually see this being practical.
I was actually just wanting to point out that this is where automatic
caching on the server shines.
> >>If it only is used once, it will actually perform worse....
>
> I didn't say it would be much worse, but it won't be faster than not
> using PREPARE.
Well, if it's not faster, that's fine. If it's worse, that's not
so fine, because as you point out there's really no way for the
driver to know whether a PreparedStatement is being used just for
speed (multiple queries with one instance) or security (on query,
but with parameters).
> I am just pointing out that I don't think the driver
> can behind the scenes use this capability automatically.
Well, if there's little or no performance impact, I would say that
the driver should always use this capability with PreparedStatement
objects. If there is a performance impact, perhaps a property could
turn it on and off?
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're
alllight. --XTC