Re: Extended Query, flush or sync ? - Mailing list pgsql-general

From Raimon Fernandez
Subject Re: Extended Query, flush or sync ?
Date
Msg-id F7F5998E-FB6D-409A-9FAA-53F1824A8ED3@montx.com
Whole thread Raw
In response to Re: Extended Query, flush or sync ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses SELECT is immediate but the UPDATE takes forever  (Raimon Fernandez <coder@montx.com>)
List pgsql-general
On 22/12/2009, at 18:15, Tom Lane wrote:

> Raimon Fernandez <coder@montx.com> writes:
>> But the portal isn't destroyed after a sync ?
>
> Not directly by a Sync, no.
>
>> I'm getting a "Portal 'myPortal' doesn't exist  "when sending the next Execute ...
>
> End of transaction would destroy portals --- are you holding a
> transaction open for this?  It's basically just like a cursor.


OK, after re-reading your email and the docs again and again, I see that portals must be inside a transaction, now it's
working... 

Here are my steps:

- parse the Selects
...
- start transaction
- bind using a prepared statement name and a portal name
- execute x n
- close transaction
...



is this the correct way ?

And in the case I limit the execute, how I can get the pending rows ?

I'm using a CURSOR with the portal just created, and it works perfectly.

Using a new execute, I'm getting again the previous rows plus the new ones, and with the CURSOR, only the pending rows
...

Is this the correct way ?


And, where I can get more info about when it's better to use an extended query, a portal, a cursor, a simple query, ...
?

thanks!


regards,



raimon

pgsql-general by date:

Previous
From: "Rajan, Pavithra "
Date:
Subject: How to get a list of tables that have a particular column value?
Next
From: Christine Penner
Date:
Subject: Re: Simple function