From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Heller <info@zilence.net>
cc: pgsql-interfaces@postgresql.org
Subject: Re: Protocol Question
In-reply-to: 
 <CAGTxmOuW94eHab4==QxzPFxVkBB16jQ2UXpYH7CRjH3r+vimNg@mail.gmail.com>
References: 
 <CAGTxmOvGwPoBC01-XnS-1cTNE29T2+QRuheQBPSrKNpbgVpmXQ@mail.gmail.com>
 <22826.1407769579@sss.pgh.pa.us>
 <CAGTxmOuW94eHab4==QxzPFxVkBB16jQ2UXpYH7CRjH3r+vimNg@mail.gmail.com>
Comments: In-reply-to Thomas Heller <info@zilence.net>
 message dated "Tue, 12 Aug 2014 17:58:45 +0200"
Date: Tue, 12 Aug 2014 18:08:48 -0400
Message-ID: <9844.1407881328@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-interfaces-owner@postgresql.org

Thomas Heller <info@zilence.net> writes:
> In an Extended Query Lifecycle, in order to prepare a query I send the
> Commands

> Parse('P') / Describe('D') / Sync('S')

> read 1/t/T/Z then to execute

> Bind('B') / Execute('E') / Flush('H')

This is not a good idea.  You *need* to use Sync to terminate a command
sequence in order to be sure of proper error recovery (because if there's
an error during the Execute, the backend will discard subsequent messages
until it sees Sync).

> If I skip the Flush after Execute I receive no data, if I Execute and Sync
> I receive the the Limit of rows and a ReadyForQuery('Z').

That's probably because you're not wrapping this in a transaction so the
Sync implicitly does a commit, discarding the open portal.  If you want
to read from a portal in multiple steps then you should issue a BEGIN
first and a COMMIT (or ROLLBACK) after you're done.  However, have you
considered just processing the data on-the-fly instead of using a limit?

			regards, tom lane


-- 
Sent via pgsql-interfaces mailing list (pgsql-interfaces@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-interfaces