Re: Protocol Question
От | Tom Lane |
---|---|
Тема | Re: Protocol Question |
Дата | |
Msg-id | 9844.1407881328@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Protocol Question (Thomas Heller <info@zilence.net>) |
Ответы |
Re: Protocol Question
|
Список | pgsql-interfaces |
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
В списке pgsql-interfaces по дате отправления: