[DB-SIG] bound parameters

Carl Karsten carl at personnelware.com
Tue Jan 9 03:42:22 CET 2007


Carsten Haese wrote:
 > On Tue, 2007-01-02 at 15:32 -0600, Carl Karsten wrote:
 >> print "#3", cur.execute("select count(*) as ncount from %(table)s", 
{'table':'logs'} )  !
 >
 > Using bound parameters for object names virtually guarantees that your
 > code is not portable to other databases.

Not surprised. not too concerned about it either.  object names are normally 
fairly sane, and not dynamic enough to worry about them cropping up later in 
production.

 > The SQL standard allows
 > placeholders only where expressions are allowed.

Is that a sql-92 thing?

I skimmed the spec and couldn't find anything.  but I may not have been looking 
for the right terms, and I sure didn't read it start to finish.

http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

 > Databases like MySQL
 > don't enforce this because they rely on string interpolation to do the
 > "parameter passing", but a real database with a real parameter passing
 > API will yell at you:
 >
 >>>> import informixdb
 >>>> conn = informixdb.connect("sysmaster")
 >>>> cur = conn.cursor()
 >>>> cur.execute("select * from ?", ("systables",) )
 > Traceback (most recent call last):
 >   File "<stdin>", line 1, in ?
 > _informixdb.ProgrammingError: SQLCODE -201 in PREPARE: 42000: Syntax error or 
access violation
 >
 > If you want true cross-database compatibility, you should use an
 > ORM/abstraction layer like SQLObject or SQLAlchemy which addresses
 > issues such as parameter styles, object naming, and even differences in
 > SQL dialects.
 >

That is actually why I am looking into this: the data classes in dabo - same 
concept as SQLObject or SQLAlchemy, different implementation.

Carl K



More information about the DB-SIG mailing list