-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeroen T. Vermeulen wrote:
> There's no actual extra parsing involved, as far as I can see, just
> pattern matching and the extraction of the variables.
That sounds like "parsing" to me. :)
[client handling the tracking of PREPARE names]
> In other words, it's only trivial to solve by the client if there
> is no possible conflict over where and how the statement got prepared.
> You say it's trivial, but you're also assuming that the work to ensure
> this has already been done. Most problems become trivial that way!
It's already been done in DBD::Pg. Naming starts at dbdpg_1 and goes to
dbdpg_2, dbdpg_3, etc. The only requirement we ask of the application
using it is that you don't prepare statements yourself named "dbdpg_x".
In most cases, the application does not worry about the naming anyway,
but simply issues an anonymous prepare request through DBIs paradigm of
one statement handle bound to a single SQL statement. DBD::Pg also does
the deallocating itself, and keeps track of the transaction status as well.
Deallocation is merely a courtesy anyway, as we don't reuse the names.
If there are flaws in the above design, I'd like to know about them,
as all of this prepare/execute stuff is rather new and undertested.
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200407041434
-----BEGIN PGP SIGNATURE-----
iD8DBQFA6E8uvJuQZxSWSsgRAivsAJwIBtULWbqxIxenRee16iIBtTDvywCfUDNT
pT7cVKHpmq0/Torj+yZkSWA=
=NzIl
-----END PGP SIGNATURE-----
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
