Re: Session state per transaction - Mailing list psycopg

From Tobias Oberstein
Subject Re: Session state per transaction
Date
Msg-id 50635D4E.1060503@gmail.com
Whole thread Raw
In response to Re: Session state per transaction  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
Responses Re: Session state per transaction
List 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 by date:

Previous
From: Daniele Varrazzo
Date:
Subject: Re: Session state per transaction
Next
From: Daniele Varrazzo
Date:
Subject: Re: Session state per transaction