[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