Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

psycopg by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group