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

Paul Moore pf_moore at yahoo.co.uk
Thu Nov 20 16:51:32 EST 2003


Anthony Tuininga <anthony at computronix.com> writes:

> This is definitely a limitation of Oracle. Oracle does not allow you to
> specify variables that are not part of the statement. As far as I know
> there is no way around this.

I thought that would be the case.

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

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

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...
-- 
This signature intentionally left blank




More information about the DB-SIG mailing list