Обсуждение: Wire protocol change

Поиск
Список
Период
Сортировка

Wire protocol change

От
Tatsuo Ishii
Дата:
If we are going to change the wire protocol, it would be nice if parse
complete message includes an identification of the previous parse
message. Same thing can be said to bind complete, command complete and
close complete.

The identification could be an either sequence number assigned to the
parse message or just the statement name (IMO sequence numbers are
better since duplicated statement names could be possible).

Background: in extended protocol, a reply to a message sent to server
could be asynchronously returned. This may raise problems with certain
applications which want to track down the reply messages. Suppose we
have:

Parse('q1')
Bind('s1', 'p1')
Execute('p1')
Parse('q2')
Bind('s2', 'p2')
Execute('p2')
Sync

The reply messages would be:

ParseComplete .. (a)
BindComplete
CommandComplete
ParseComplete .. (b)
BindComplete
CommandComplete
ReadyForQuery

Since (a) and (b) are compeletely identical message, it's not easy to
ditinguish which a and b.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



Re: Wire protocol change

От
Tom Lane
Дата:
Tatsuo Ishii <ishii@postgresql.org> writes:
> If we are going to change the wire protocol, it would be nice if parse
> complete message includes an identification of the previous parse
> message. Same thing can be said to bind complete, command complete and
> close complete.

> The identification could be an either sequence number assigned to the
> parse message or just the statement name (IMO sequence numbers are
> better since duplicated statement names could be possible).

> Background: in extended protocol, a reply to a message sent to server
> could be asynchronously returned.

Uh, what?  There's no asynchrony in the protocol --- messages are
processed and answered strictly in order.  I grant that certain types
of application structures might find it convenient if we numbered the
responses, but it seems like mostly a waste of network bandwidth.
The application should be able to count the results for itself.

In any case, if the server simply numbers the responses, how does that
help?  In the example you show, the ParseComplete messages might come
back with numbers 42 and 43 --- exactly how does that help the app
associate them with the commands it sent?
        regards, tom lane