Re: [RFC] ideas for a new Python DBAPI driver (was Re: libpq test suite)

Поиск
Список
Период
Сортировка
От Daniele Varrazzo
Тема Re: [RFC] ideas for a new Python DBAPI driver (was Re: libpq test suite)
Дата
Msg-id CA+mi_8YAmoK+pOhO8R995=O9RYYC_c4sgtCrCVxSRRo--f3x8w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [RFC] ideas for a new Python DBAPI driver (was Re: libpq test suite)  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On Fri, Feb 15, 2013 at 9:28 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On 2/14/13 2:42 PM, Marko Tiikkaja wrote:
>>> I think the reason this doesn't work is that in order to prepare a query
>>> you need to know the parameter types, but you don't know that in Python,
>>> or at least with the way the DB-API works.  For example, if you write
>>>
>>> cur.execute("SELECT * FROM tbl WHERE a = %s AND b = %s", (val1, val2))
>>>
>>> what types will you pass to PQsendQueryParams?
>>
>> Pardon me if this is obvious, but why would you need to pass any types
>> at all?  Assuming we're still talking about PQsendQueryParams and not an
>> explicit prepare/execute cycle..
>
> Well, PQsendQueryParams() requires types to be passed, doesn't it?

No, not necessarily: they are inferred by the context if they are not specified.

I've had in mind for a long time to use the *Params() functions in
psycopg (although it would be largely not backwards compatible, hence
to be done on user request and not by default). Psycopg has all the
degrees of freedom in keeping the two implementations alive (the
non-*params for backward compatibility, the *params for future usage).
I'd drafted a plan on the psycopg ML some times ago. But I don't have
a timeline for that: it's a major work and without pressing
motivations to do it.

-- Daniele



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [RFC] ideas for a new Python DBAPI driver (was Re: libpq test suite)
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: Materialized views WIP patch