Re: Using real libpq parameters
От | Federico Di Gregorio |
---|---|
Тема | Re: Using real libpq parameters |
Дата | |
Msg-id | 4D6A3810.5060300@dndg.it обсуждение исходный текст |
Ответ на | Using real libpq parameters (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Список | psycopg |
On 27/02/11 00:40, Daniele Varrazzo wrote: [snip] > Luckily (well, it wasn't luck at all: thanks to Federico's design) > psycopg already has two extension mechanisms to cope with having both > the execution methods: one is the possibility to subclass > connections/cursors and thus have a cursor supporting PQexecParams in > execute() and PQprepare in executemany() (let's call it ParamCursor). > Another one is the completely generic adaptation mechanism of Python > objects [5]: there could be a separate protocol (let's say ISQLParam) > to which python object passed to the query should be conformed: > conforming object may expose different methods from the ones required > by ISQLQuote, that may be needed to interface with PQexecParam. If you have a look at ISQLQuote empty implementation you'll see a getbinary() method that was put there exactly for the reason of supporting PQexecParams & co. At the time the idea was that an adapter *should* provide a method to convert the adapted object to PostgreSQL binary representation. As Daniele explained the main problem is that not every value can be converted to binary representation so, probably, a separate protocol would be better. About the API I'd probably go for complete transparency: if every parameter supports the new protocol, then adapt to binary, else just fall back to the current implementation. Checking the parameters should be quite fast (the code don't really adapt anything yet). federico -- Federico Di Gregorio federico.digregorio@dndg.it Studio Associato Di Nunzio e Di Gregorio http://dndg.it Lord, defend me from my friends; I can account for my enemies. -- Charles D'Hericault
В списке psycopg по дате отправления: