Re: Proposal: http2 wire format

It could make sense to arrange a Google Hangouts conversation (or alike).
Hangouts allows to record sessions with up to 10 speakers and unlimited
listeners. The recording can be shared via YouTube.

Damir>Funny you agree with that—for someone having the experience of
writing a driver and having a long list of things that you find wrong and
frustrating

I've been contributing to pgjdbc since 2014, so I do know how "great" v3 is.
I wish there was a machine-readable protocol definition (e.g. Apache Thrift
and/or GRPC and/or ProtoBuf etc).

However, I fully agree with Tom that a mere usage of HTTP/2 would just
render havoc with little outcome. Just to make it clear: HTTP/2 does not
solve "hard to parse", "hard to load-balance", "hard to proxy" v3 problems,
and it creates a huge problem of "let's reimplement HTTP2 client for all
the clients/languages".

Of course HTTP/2 stream multiplexing could be extremely helpful. For
QueryCancel commands and/or for hearbeat messages. However those things
alone do not justify the use of low-level HTTP/2.

Damir>Why parse some obscure Postgres-specific binary data types when you
can have the database send you the data in the serialization format of your
client language?

Suppose you want to use prepared statement.
Then you need to do it in sequence:
1) Parse SQL text and convert it to a handle
2) Bind parameter value to the handle
3) Execute the statement
4) Receive rows
5) Receive error if any

Currently it is implemented via different v3 messages (parse, bind,
execute, row description, data row, etc etc).

The claim is *any* implementation "on top of HTTP/2" would basically
require to implement those "parse, bind, execute, row data, etc" *messages*.
Say you pick to use "/parse" url with SQL text in body instead of "parse
message". It does not make the whole thing "just HTTP/2". It just means
you've created "your own protocol on top of HTTP/2".

Clients would have to know the sequence of valid messages,
clients would have to know if SQL should be present in body or in URL or in
form post data, etc, etc.

I believe Andres means exactly the same thing as he says

By the way: you cannot just "load balance" "parse/bind/exec" to different
backends, so the load balancer should be aware of meaning of those
"parse/bind/exec" messages. I believe that is one of the requirements Craig
meant by "Is practical to implement in connection pooler proxies".

Andres>You *still* need a full blown protocol ontop of it. So no, this
doesn't change that

Damir> Did you know that Go has HTTP2 support in the standard library? And
so does java, too?

Java has TCP implementation in the standard library.
Does it help implementing v3 protocol?
In the same way HTTP/2 "as a library" helps implementing v4. The problem is
it does not. Developer would have to somehow code the coding rules (e.g.
header names, body formats).
HTTP/2 is just too low level.

Damir>Why parse some obscure Postgres-specific binary data types when you
can have the database send you the data in the serialization format of your
client language?

From my own experience, automatic use of server-prepared statements (see
https://github.com/pgjdbc/pgjdbc/pull/319 ) did cut end-user response times
of our business application in half.
That is clients would have to know the way to use prepared statements in
order to get decent performance.
If you agree with that, then "v3 parse message", "v3 bind message", "v3
execute message" is not that different from "HTTP/2 POST to /parse",
"HTTP/2 POST to /bind", "HTTP/2 POST to /execute". It is still "obscure
PostgreSQL-specific HTTP/2 calls".

Even if you disagree (really?) you would still have to know
PostgreSQL-specific way to encode SQL text and "number of rows returned"
and "wire formats for the columns" even for a single "HTTP POST
/just/execute/sql" kind of API. Even that is "a full blown protocol
ontop of HTTP2"
(c) Andres.

Vladimir