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.

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