From: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
---|---|
To: | Tobias Oberstein <tobias(dot)oberstein(at)gmail(dot)com> |
Cc: | psycopg(at)postgresql(dot)org |
Subject: | Re: Session state per transaction |
Date: | 2012-09-26 22:58:06 |
Message-ID: | CA+mi_8a9UORBUmcSm5vABqZFWoEvrSOjaz8BaNMx28cx_Dy0Ow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
On Wed, Sep 26, 2012 at 8:53 PM, Tobias Oberstein
<tobias(dot)oberstein(at)gmail(dot)com> wrote:
>> This is one of these things that would stop work moving to
>> PQexecParams: that's why I want to make sure to leave open the
>> possibility to keep on using PQexec even if we move to the *Params
>> functions.
>
> Guess you refer to (which I here reproduce for others who might wonder):
>
> Unlike PQexec, PQexecParams allows at most one SQL command in the given
> string.
>
> http://www.postgresql.org/docs/9.2/static/libpq-exec.html
Correct.
> Btw: does Psycopg currently use PQprepare/PQexecPrepared ?
Not yet: note that these function are very similar in signature to
PQexecParams: supporting the latter would bring us closer to use
prepare statement.
Note 2: you can still prepare a statement in sql using the PREPARE
statement, and this can currently be used by psycopg.
But for both the methods, one question remains: how to use statement
preparation? prepare() at each execute() seems overkilling if you have
to execute a statement only once. An obvious place that would benefit
of preparation is executemany(): we could prepare the query once on
the query and execPrepared once for each item.
Still there is an important use case: in a connection, using one or
several cursors, the same query could be repeated over and over. So
what?
- should we have a prepare() method to be called to manually prepare a
query? How to refer to the prepared query? Should prepare return a
name/opaque object? Should it just intern the string and detect that
the same query is used by execute()?
- should we have a connection subclass preparing all the queries you
throw at it (until a certain limit after which start discarding the
older ones)?
So, I'd say once we know how we would use a prepare/execute feature we
can implement it. In the meanwhile the feature can be somewhat
prototyped by subclassing connection and cursor and mangling the
queries with a PREPARE statement, with which we can use the current
psycopg parameters adaptation.
-- Daniele
From | Date | Subject | |
---|---|---|---|
Next Message | Federico Di Gregorio | 2012-09-27 07:21:15 | Re: Session state per transaction |
Previous Message | Tobias Oberstein | 2012-09-26 19:53:50 | Re: Session state per transaction |