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

From: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Marko Tiikkaja <pgmail(at)joh(dot)to>, Manlio Perillo <manlio(dot)perillo(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [RFC] ideas for a new Python DBAPI driver (was Re: libpq test suite)
Date: 2013-02-15 23:11:40
Message-ID: CA+mi_8YAmoK+pOhO8R995=O9RYYC_c4sgtCrCVxSRRo--f3x8w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 15, 2013 at 9:28 PM, Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-02-15 23:46:37 Re: BUG #7873: pg_restore --clean tries to drop tables that don't exist
Previous Message Dave Rolsky 2013-02-15 22:06:12 Re: BUG #7873: pg_restore --clean tries to drop tables that don't exist