Re: Session state per transaction
От | Tobias Oberstein |
---|---|
Тема | Re: Session state per transaction |
Дата | |
Msg-id | 50635D4E.1060503@gmail.com обсуждение исходный текст |
Ответ на | Re: Session state per transaction (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Ответы |
Re: Session state per transaction
|
Список | psycopg |
> If the double roundtrip is the problem you can send the two queries > together, and take care in your code to send the first only once per > user request > > cur.execute(""" > SELECT set_config('webmq.sessionid', %s, false); > SELECT mysp1(%s, %s)""", > [session_id, ...]) > Great! That's sufficient. I wasn't aware concatenating statements works like that. > 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): "The primary advantage of PQexecParams over PQexec is that parameter values can be separated from the command string, thus avoiding the need for tedious and error-prone quoting and escaping. Unlike PQexec, PQexecParams allows at most one SQL command in the given string. (There can be semicolons in it, but not more than one nonempty command.) This is a limitation of the underlying protocol, but has some usefulness as an extra defense against SQL-injection attacks." http://www.postgresql.org/docs/9.2/static/libpq-exec.html === Btw: does Psycopg currently use PQprepare/PQexecPrepared ? Thanks for your help, Tobias > > -- Daniele >
В списке psycopg по дате отправления: