Re: Session state per transaction

From: Tobias Oberstein <tobias(dot)oberstein(at)gmail(dot)com>
To: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
Cc: psycopg(at)postgresql(dot)org
Subject: Re: Session state per transaction
Date: 2012-09-26 19:53:50
Message-ID: 50635D4E.1060503@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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
>

In response to

Responses

Browse psycopg by date

  From Date Subject
Next Message Daniele Varrazzo 2012-09-26 22:58:06 Re: Session state per transaction
Previous Message Daniele Varrazzo 2012-09-26 18:34:29 Re: Session state per transaction