Tatsuo Ishii-4 wrote
>
> 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.
>
> If this is true, that means unnamed portal execution and named portal
> execution cannot be mixed unless they are inside an explicit
> transaction. IMO this should be described in the document.
My relatively uninformed conclusions from reading this thread and
documentation excerpts:
Correct.
In the absence of an explicit transaction only a single logical query can be
executed "per transaction". #2 should be disallowed, though, as opposed to
#4 failing since the second PARSE implies a second logical query being
formed which should not occur outside an explicit transaction.
"At completion of each series of extended-query messages, the frontend
should issue a Sync message."
I take this phrase to mean that a logical sequence is defined as:
PARSE -> (BIND -> EXECUTE){1,} -> SYNC
If you are within an explicit transaction you are brought back to point
where the next PARSE can be issued and thus a new statement - within the
same transaction - can be issued. If you are not within an explicit
transaction the SYNC effectively causes a "COMMIT;" to be issued on the
back-end thus the unnamed statement and unnamed portal are both closed. If
the resultant portal is named and defined with "FOR HOLD" the named portal
will continue to exist while the named (or unnamed for that matter)
statement will be closed.
The documentation makes the assumption that you understand the "single
statement" nature of implicit transactions. Given the level of knowledge
needed to operate with the frontend protocol this is not necessarily
unreasonable. I guess my question is whether the backend fails in the
situation of an implicit transaction and two PARSE messages without an
intervening SYNC. If not then when is it reasonable to issue two PARSE
statements in this manner?
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Question-regarding-Sync-message-and-unnamed-portal-tp5726023p5770365.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
