[DB-SIG] Towards a single parameter style
Federico Di Gregorio
fog@initd.org
21 Feb 2003 15:09:13 +0100
--=-/g74AMs4QgVTr0SKkloE
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Il ven, 2003-02-21 alle 04:33, Stuart Bishop ha scritto:
> On Wednesday, February 19, 2003, at 10:59 PM, Kevin Jacobs wrote:
>=20
> > This requires storing a cursor for each prepared command, and still=20
> > does not
> > address the main point of prepared statements -- they only make sense=20
> > if you
> > call them many times! DB-API 2.0 provides a simplistic version of this
> > concept -- executemany -- though it requires that all of the arguments=20
> > are
> > available at once, and does not allow any other statements interleaved
> > between them.
>=20
> Passing the same string to cursor.execute should re-execute the already
> prepared statement if it already exists.
prepared statements are usefull only ona bunch of db backends that
support such stuff (and through odbc). i am absolutely against prepared
statements, goven the fact that a lot of db will be penalized by them.
executemany is much better, because can be implemented the right way for
both typpes of db.
note: the python dbapi is great because it frees the user from a lot of
low level details. implicit transaction begin is good. executemany is
good. why introduce a lot of db-specific concepts?
--=20
Federico Di Gregorio
Debian GNU/Linux Developer fog@debian.org
INIT.D Developer fog@initd.org
Don't dream it. Be it. -- Dr. Frank'n'further
--=-/g74AMs4QgVTr0SKkloE
Content-Type: application/pgp-signature; name=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQA+VjMIvcCgrgZGjesRAi7QAJsEFysjtn6yIx62A4HAWIu8hJKVGwCeK5ej
oaqO2vlhN3ff/5I222WiIlo=
=gdV6
-----END PGP SIGNATURE-----
--=-/g74AMs4QgVTr0SKkloE--