Re: [RFC] ideas for a new Python DBAPI driver (was Re: libpq test suite) - Mailing list pgsql-hackers

From Daniele Varrazzo
Subject Re: [RFC] ideas for a new Python DBAPI driver (was Re: libpq test suite)
Date
Msg-id CA+mi_8YAmoK+pOhO8R995=O9RYYC_c4sgtCrCVxSRRo--f3x8w@mail.gmail.com
Whole thread Raw
In response to Re: [RFC] ideas for a new Python DBAPI driver (was Re: libpq test suite)  (Peter Eisentraut <peter_e@gmx.net>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [RFC] ideas for a new Python DBAPI driver (was Re: libpq test suite)
Next
From: Kevin Grittner
Date:
Subject: Re: Materialized views WIP patch