Re: Proposal: http2 wire format - Mailing list pgsql-hackers

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