[DB-SIG] Re: cx_Oracle - passing unnecessary bind variables

Anthony Tuininga anthony at computronix.com
Thu Nov 20 17:10:00 EST 2003

On Thu, 2003-11-20 at 14:51, Paul Moore wrote:
> Anthony Tuininga <anthony at computronix.com> writes:
> > Oracle does provide a way of returning to you the bind variable
> > names once the statement is prepared but cx_Oracle does not
> > (currently) provide that information. I have another workaround for
> > now but if you really think this would be helpful, feel free to ask
> > me for it -- this is definitely beyond the scope of the DB API but I
> > have long since stopped feeling restricted by the limitations of the
> > API (which has to accommodate each of the different database
> > management systems out there).
> It's pretty specialised, so I can't say I feel a burning need for it,
> but it might be nice to have available. I agree with you over DB-API
> compatibility. It's very good to have a standardised subset, but for
> real applications (even small ones) I'd generally prefer to be able to
> get at database-specific features, and use them to exploit the
> features of the database.

I'll see how simple this is to accomplish. If it is easy and I have the
time, I'll add it; otherwise, I'll leave it alone.

> > Oracle does make this information available once the statement is
> > prepared but if you want something quicker (but less "nice") than I can
> > suggest the following:
> Yes, I actually thought of that just a couple of minutes ago. It's
> perfectly adequate, I'd say - a clear case of "practicality beats
> purity".
> Thanks for the help!

No problem.

> Paul.
> PS On an unrelated note, have you considered using the Python 2.3
>    datetime objects instead of cx_Oracle's Date/Time/Timestamp types?
>    I believe that you could do this with virtually no change to the
>    visible API - you'd lose the "fsecond" attribute of the date
>    object, but I think that's all. It would make interacting with
>    standard Python a little less tedious...

Definitely thought about it. Intending to implement it as well as the
ability to subclass connections, cursors, etc. That scale of changes
suggests to me 4.0 and will eliminate support for Python 2.1 and
earlier. That said, I have branched in CVS so if anyone really needs a
change that is compatible with Python 2.1 or earlier it won't be a

Anthony Tuininga
anthony at computronix.com
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838

More information about the DB-SIG mailing list