Re: protocol-level wait-for-LSN

>> So yes, each protocol extension needs to know about all the other
>> protocol extensions that it can be used with. In practice we'll avoid
>> doing crazy stuff so that the protocol extensions are orthogonal
>
> Just as an example, let's say we add a server-side query time to the
> protocol (which honestly seems like a pretty useful feature). So that
> ReadyForQuery now returns the query time if the query_time protocol.
> For clients it isn't difficult at all to support any combination of
> query_time & wait_for_lsn options. As long as we define that the
> wait_for_lsn field is before the query_time field if both exist, then
> two simple if statements like this would do the trick:
>
> if (wait_for_lsn_enabled) {
> // interpret next field as LSN
> }
> if (query_time_enabled) {
> // interpret next field as query time
> }

But

if (query_time_enabled) {
// interpret next field as query time
}
if (wait_for_lsn_enabled) {
// interpret next field as LSN
}

doesn't work, right? I don't like clients need to know the exact order
of each protocol extensions.

BTW,

> Just as an example, let's say we add a server-side query time to the
> protocol (which honestly seems like a pretty useful feature). So that
> ReadyForQuery now returns the query time if the query_time protocol.

Probaby it's better CommandComplete returns the query time because
there could be multiple query-time in multi-statement query or
extended query protocol.

Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp