Tatsuo Ishii <is...@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.
> 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.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
