views:

3989

answers:

6

Hello,

For some reasons, I would like to do an explicit quoting of a string value (becoming a part of constructed SQL query) instead of waiting for implicit quotation performed by cursor.execute method on contents of its second parameter.

By "implicit quotation" I mean:

value = "Unsafe string"
query = "SELECT * FROM some_table WHERE some_char_field = %s;"
cursor.execute( query, (value,) ) # value will be correctly quoted

I would prefer something like that:

value = "Unsafe string"
query = "SELECT * FROM some_table WHERE some_char_field = %s;" % \
    READY_TO_USE_QUOTING_FUNCTION(value)
cursor.execute( query ) # value will be correctly quoted, too

Is such low level READY_TO_USE_QUOTING_FUNCTION expected by Python DB API specification (I couldn't find such functionality in PEP 249 document). If not, maybe Psycopg2 provides such function? If not, maybe Django provides such function? I would prefer not to write such function myself...

A: 

This is going to be DB dependent. In the case of MySQLdb, for example, the connection class has a literal method that will convert the value to the correct escaped representation for passing to MySQL (that's what cursor.execute uses).

I imagine Postgres has something similar, but I don't think there is a function to escape values as part of the DB API 2.0 spec.

davidavr
A: 

This'll be database dependent (iirc, mysql allows \ as an escape character, while something like oracle expects quotes to be doubled: 'my '' quoted string').

Someone correct me if i'm wrong, but the double-quoting method is the standard method.

It may be worth looking at what other db abstraction libraries do (sqlalchemy, cx_Oracle, sqlite, etc).

I've got to ask - why do you want to inline the values instead of bind them?

Richard Levasseur
I have a lots of rather non trivial queries which contain some repeating patterns (e.g. sets of multiple WHERE conditions). I've defined some classes which encapsulate necessary data and SQL generating code. It would be uncomfortable to return separately SQL code and param sequence from them.
Dariusz Walczak
FWIW when dealing with complex query generation I usually do pass back a parameterised query string and separate param list. It's not really that bad.
bobince
+2  A: 

You should try to avoid doing your own quoting. Not only will it be DB-specific as people have pointed out, but flaws in quoting are the source of SQL injection bugs.

If you don't want to pass around queries and values separately, then pass around a list of the parameters:

def make_my_query():
    # ...
    return sql, (value1, value2)

def do_it():
    query = make_my_query()
    cursor.execute(*query)

(I probably have the syntax of cursor.execute wrong) The point here is that just because cursor.execute takes a number of arguments, that doesn't mean you have to handle them all separately. You can deal with them as one list.

Ned Batchelder
You can also pass them as a dict:cursor.execute( "SOME SQL %(aparam)s, %(another)s, %(aparam)s", adict)
Brian C. Lane
Still, this won't work in all cases; it's afaict impossible to make that work when doing multi-row inserts and similar constructs.
Henrik Gustafsson
Whatever structure of database calls you need to make, you can build an abstraction to hold the data until it's time to use it. Wanting to build queries abstractly is no excuse for hacking together your own quoting.
Ned Batchelder
Certainly true, but at some point you do need to quote your data no matter how many layers of abstraction you hide it beneath, and the mechanisms provided by execute/executemany can not support all uses of values in SQL.
Henrik Gustafsson
Ok, so it's possible to do eg. sql = 'insert into x values'+','.join(('(%s, %s)',) * len(values)) and so on, but I don't find that a very good solution.
Henrik Gustafsson
I fully agree that I shouldn't write my own quoting function (this is why I've asked the question). :-) I thought about returning param values as a list/dict together with SQL string but IMHO it's bug prone in case of more than one "SQL generator" (I generate parts of SQL, e.g. sets of WHERE conds).
Dariusz Walczak
+9  A: 

Ok, so I was curious and went and looked at the source of psycopg2. Turns out I didn't have to go further than the examples folder :)

And yes, this is psycopg2-specific. Basically, if you just want to quote a string you'd do this:

from psycopg2.extensions import adapt

print adapt("Hello World'; DROP DATABASE World;")

But what you probably want to do is to write and register your own adapter;

In the examples folder of psycopg2 you find the file 'myfirstrecipe.py' there is an example of how to cast and quote a specific type in a special way.

If you have objects for the stuff you want to do, you can just create an adapter that conforms to the 'IPsycopgSQLQuote' protocol (see pydocs for the myfirstrecipe.py-example...actually that's the only reference I can find to that name) that quotes your object and then registering it like so:

from psycopg2.extensions import register_adapter

register_adapter(mytype, myadapter)

Also, the other examples are interesting; esp. 'dialtone.py' and 'simple.py'.

Henrik Gustafsson
It looks that your solution is what I sought. If I use default adapter for quoting string values (to use it as string constants) will it prevent me against SQL injection? It looks so but maybe I miss something...
Dariusz Walczak
I'm pretty sure that's the intent....whether it actually works I don't know.
Henrik Gustafsson
I'll use it. Thank you very much.
Dariusz Walczak
A: 

If you use django you might want to use the quoting function which is automatically adapted to the currently configured DBMS :

from django.db import backend
my_quoted_variable = backend.DatabaseOperations().quote_name(myvar)
vincent
`quote_name` encloses result string with double quotation marks. PostgreSQL (8.2.5) doesn't allow it as string constant delimiters (it looks they are used for so called quoted identifiers). Using function provided by django would be best for me, unfortunately I don't see proper function in db ops.
Dariusz Walczak
Looks like I'm completely wrong, quote_name is for escaping table and column names !
vincent
A: 

I don't think you give any sufficient reasoning behind your avoidance to do this The Right Way. Please, use the APi as it is designed and don't try so hard to make your code less readable for the next guy and more fragile.

ironfroggy
"...WHERE some_field IN (%s)" % ", ".join(...well, what?..)
Roman Odaisky
Then I would do something like "... WHERE some_field IN (%s)" % ",".join('%s') and generate the parameterized query. I can then still apply the parameter values afterwards.
ironfroggy