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
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 |