[DB-SIG] Re: [PyGreSQL] Version 3.0 PyGreSQL

M.-A. Lemburg mal@lemburg.com
Fri, 12 May 2000 12:37:17 +0200

Greg Stein wrote:
> On Fri, 12 May 2000, M.-A. Lemburg wrote:
> >...
> > One addition which I tried in the mxODBC was the addition
> > of a .prepare(command) method and a .command read-only
> > attribute.
> >
> > The .prepare() method allows preparing a command for execution
> > on the cursor *without* actually executing it. The .command
> > attribute is always set to the currently cached command
> > on the cursor. Now, to execute a prepared command, all you
> > have to do is pass .command to the .execute() method as
> > command. Then the re-use optimization will notice that you
> > are executing a prepared command and skip the normally
> > needed prepare step -- very useful for pooling cursors
> > with often used commands such as id-name mappings etc.
> Understood, but I've never seen the utility of doing the prepare() ahead
> of time (as opposed to simply waiting for that first execution to occur).
> After that point, the current mechanism and your prepare/command are
> equivalent.

As I said: it's very useful for implementing a cursor pool. That's
what I use it for with great success (ODBC allows you to separate
the prepare and execute step, so adding .prepare() was no big

> Introducing prepare/command is Yet More Stuff for a person to deal with.

It's optional, so if a DB interface writer doesn't like,
she doesn't have to implement it.

Marc-Andre Lemburg
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/