[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--