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  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Daniele Varrazzo
Дата:
Сообщение: Re: Session state per transaction
Следующее
От: Daniele Varrazzo
Дата:
Сообщение: Re: Session state per transaction