From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Heller <info(at)zilence(dot)net> |
Cc: | pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: Protocol Question |
Date: | 2014-08-12 22:08:48 |
Message-ID: | 9844.1407881328@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
Thomas Heller <info(at)zilence(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Heller | 2014-08-13 00:09:40 | Re: Protocol Question |
Previous Message | Thomas Heller | 2014-08-12 15:58:45 | Re: Protocol Question |