[DB-SIG] SQL statement parse for Oracle

[M.-A. Lemburg]

Anthony Tuininga wrote:
> 
> Ok, that sounds reasonable. I have one question, though. Is the last
> ".command" meant to be ".statement"? 

I called it .command because the SQL you execute is not always a 
statement.

> In other words, is the statement
> that is prepared stored with the cursor and then also passed to the
> execute function? Like this?
> 
> cursor.prepare("SQL")
> cursor.execute(cursor.statement, parameters)

Yes, that's the idea. This is needed in order to make the whole
thing compatible to the .executexxx() methods.
 
> If that is what is intended, I can live with that as there is a simple
> pointer comparison in order to determine if the statement ought to be
> parsed or not.

Right, that's the idea -- you sort of reuse the .execute() caching
idea for separating the two steps.
 
> M.-A. Lemburg wrote:
> >Perhaps I should add a .prepare() method to the set of standard
> >DB API extensions though ?!
> >
> >Here's what I have in mxODBC:
> >
> >   .prepare(operation)
> >
> >        Prepare a database operation (query or command) statement for
> >        later execution and set cursor.command.
> >        To execute a prepared statement, pass
> >        cursor.statement to one of the .executeXXX() methods.
> >        Return values are not defined.
> >
> >and
> >
> >   .command
> >
> >        Provides access to the last prepared or executed SQL command
> >        available through the cursor. If no such command is available,
> >        None is returned.
> >

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/