Re: [psycopg] Solving the SQL composition problem
От | Jim Nasby |
---|---|
Тема | Re: [psycopg] Solving the SQL composition problem |
Дата | |
Msg-id | 1e7d531c-c952-95b9-35bc-a91e9535a5b4@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: [psycopg] Solving the SQL composition problem (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Ответы |
Re: [psycopg] Solving the SQL composition problem
Re: [psycopg] Solving the SQL composition problem Re: [psycopg] Solving the SQL composition problem |
Список | psycopg |
On 1/2/17 10:21 AM, Daniele Varrazzo wrote: >> execute('insert into %s values ($1)', [42], ['my table']) >> >> Obviously this would be backwards incompatible, but I think that's >> manageable. > mmm... what I think is that if these objects' replacement rules were > different one could leave the %s and %(name)s placeholder untouched > for the query params. > > A natural choice could be to use the str.format syntax for the query > composition, or a subset of it. Hence my example could be: > > cur.execute( > sql.SQL("insert into {} values (%s, > %s)").format(sql.Identifier('my_table')), > [10, 20]) > > This would largely remove the need for double escaping. What I'm suggesting is to let Postgres handle the replacement of normal values, using the prepared statement syntax of $1, $2, etc[1], and only do identifier replacement in python (using quote_ident). That means a lot less time spent parsing, and opens the door for eventually doing more efficient stuff over the wire, like using binary type formats. 1: https://www.postgresql.org/docs/current/static/sql-prepare.html -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532)
В списке psycopg по дате отправления: