> Tatsuo Ishii <ishii@postgresql.org> writes:
>> From the manual:
>> "An unnamed portal is destroyed at the end of the transaction"
>
> Actually, all portals are destroyed at end of transaction (unless
> they're from holdable cursors). Named or not doesn't enter into it.
We need to fix the document then.
>> From these statements, I would think #4 will fail in the following
>> sequence of commands because #3 closes transaction and it destroys
>> unnamed portal: 1)Parse/Bind creates unnamed portal,
>> 2)Parse/Bind/Execute creates named portal and executes, 3)Send Sync
>> message (because it is required in extended protocol), 4)Execute
>> unnamed portal created in #1.
>
> The right thing to use if you're trying to interleave portal executions
> like that is Flush, not Sync. Sync mainly adds a protocol
> resynchronization point --- it's needed in case portal execution fails
> partway through. (In which case you'll have lost both portals in the
> transaction abort anyway.)
Thanks for the suggestion. However, problem with using Flush is,
backend never sends "Ready for Query" until Sync is sent. For frontend
program "Ready for query" is important because 1) client knows session
state, 2) "Ready for query" is a command boundary as stated in
document.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp