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
