Обсуждение: Extended query protocol violation?

While playing with Java application using JDBC driver, I noticed
an interesting fact:

When autocommit is off, JDBC driver issues following messages:

20:10:54.731 (2)  FE=> Parse(stmt=S_1,query="BEGIN",oids={})
20:10:54.731 (2)  FE=> Bind(stmt=S_1,portal=null)
20:10:54.731 (2)  FE=> Execute(portal=null,limit=0)
20:10:54.732 (2)  FE=> Parse(stmt=null,query="SELECT ...
20:10:54.733 (2)  FE=> Bind(stmt=null,portal=null)
20:10:54.733 (2)  FE=> Describe(portal=null)
20:10:54.733 (2)  FE=> Execute(portal=null,limit=0)
20:10:54.733 (2)  FE=> Sync
20:10:54.734 (2)  <=BE ParseComplete [S_1]
20:10:54.734 (2)  <=BE BindComplete [null]
20:10:54.734 (2)  <=BE CommandStatus(BEGIN)
20:10:54.735 (2)  <=BE ParseComplete [null]
20:10:54.735 (2)  <=BE BindComplete [null]
20:10:54.735 (2)  <=BE RowDescription(15)

Notice that JDBC driver sends Parse, Bind and Execute without Sync
followed then immediately sends another Parse message.  I wonder if
this violates our extended query protocol.  From the manual:

"At completion of each series of extended-query messages, the frontend
should issue a Sync message."

"each series of extended-query messages" is a little vague here but it
seems it referes to a sequence of message starting with parse and
ending with execute message to me. If so, I think above example of
message sequence violates the protocol.

The application produces the packet sequence is essentially like this:

connection.setAutoCommit(false);
stmt = connection.createStatement();
rs = stmt.executeQuery(sql);        
Comments?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Tatsuo Ishii <ishii@postgresql.org> writes:
> Notice that JDBC driver sends Parse, Bind and Execute without Sync
> followed then immediately sends another Parse message.

> I wonder if this violates our extended query protocol.

It does not.

> "At completion of each series of extended-query messages, the frontend
> should issue a Sync message."

That's a "should", not a "must".  The important point here is that if the
BEGIN were to fail for some reason, the backend would skip the second
command altogether, since it would skip to the Sync before resuming
processing messages.  If the JDBC driver isn't expecting that behavior,
that's a bug in the driver --- but it's not a protocol violation.  In
fact, the protocol is intentionally designed to let you stack up commands
like that.  It gives you a tradeoff of potential concurrency vs possible
complexity in error recovery handling.
        regards, tom lane