Every serious database driver has a complete and solid SQL escaping
mechanism. This mechanism tipically involves putting placeholders in
your SQL strings and passing python data in a separate tuple or
dictionary. Kinda
cur.execute("INSERT INTO datatable (data) VALUES (%s);",
(pickled_data,))
instead of:
cur.execute("INSERT INTO datatable (data) VALUES ('%s');" %
(pickled_data,))
It is the driver responsibility to serialize the data (which usually
involves adding enclosing quotes and escape odd charaters such as
quotes themselves).
What database/driver are you using? PostgreSQL+psycopg2 or any other
wrong one? ;) In eiither case, read the driver documentation and the
DBAPI documentation (http://www.python.org/dev/peps/pep-0249/) for
further details.
-- Daniele
any Idea what could be done with the mysql python module I am using?
regards,
Krishnakant.
OK: MySQLdb implements the escaping mechanism i described. You can
find the documentation if you look for it harder.
> I did not find any such reference to storing pickled objects in the API.
Storing pickled object is not different from storing anything else
into BLOB. You would have faced the same problem if you had to write
"O'Reilly" in a VARCHAR field.
-- Daniele
cur.execute("INSERT INTO datatable (data) VALUES (?);" , (pickled_data,))
Then the DB driver will take care for you.
>>> import MySQLdb
>>> print MySQLdb.paramstyle
format
MySQLdb (as many other drivers) use format parameter passing. Not much
difference w.r.t. qmark, at least when passing positional parameters:
the placeholder is "%s" instead of "?". A difference is that "format"
also allows named parameters (actually it should have been "pyformat",
but IIRC MySQLdb can also use named placeholders, even if they
advertise "format").
Anyway it is only a matter of placeholder style: they both allow the
driver to take care of data escaping, the concept the OT didn't know
about.
-- Daniele
Cheers,
Stefan
> %s is not a placeholder IMHO.
> What happens when using %s is, that the string given will be inserted where
> %s is; that is something python does as with every print or such.
It is indeed. The behavior you describe would be true if i had used
the "%" operator. Read better what i have written: There is no "%"
operator.
cur.execute() receives 2 parameters: a SQL string with placeholders
and a tuple with values: it's not me mangling values into the SQL
string. This is the driver responsibility and it has the chance
because it receives SQL and values as two distinct parameters. The
driver can ask the SQL string to contain placeholders either in qmark
"?" or in format "%s" style, but there is no functional difference.
Notice that the placeholder is always "%s" and not "%d" or "%f" for
integers or float: there is always an escaping phase converting each
python object into a properly encoded string and then the placeholders
are replaced with the value. This happens into the execute()
machinery.
> By using the qmark style, it is up the the implementation of the
> cursor.execute method to decide what to do. python itself, and it's string
> implementation, don't know anything to do with the qmark.
> So, IMHO it *makes* a difference:
> with %s the execute function sees a string and nothing more as the
> parameters are consumed away by the % substitution.
> with ?, the execute implementation must do it's best, it gets a string and
> a list/tuple with values.
Again, this would be true for "cur.execute(sql % data)": what i wrote
is "cur.execute(sql, data)".
-- Daniele
My fault: the difference is hard to spot indeed in the rather long
line of the example. I should have been more explicit stating that the
differences were:
1. missing explicit quotes around the placeholders (they are part of
the escaped values),
2. no % operator: two parameters are passed instead.
Best regards,
-- Daniele
This confusion is precisely why I think the (py)format paramstyles
should be deprecated in a future version of the DB-API spec. Question
marks make it immediately obvious that something other than string
formatting is happening, and if I'm not mistaken, question marks are SQL
standard.
--
Carsten Haese
http://informixdb.sourceforge.net
A deprecation warning for now would be fine.