Re: Proposal: http2 wire format

> 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*.

Why? Wouldn’t you be able to package that into a single request with query in the data frame and params as headers?

> 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”.

It is new functionality, isn’t it? Of course you have to evolve protocol semantics for that. That’s the whole point! HTTP2 is just a nice substrate that comes with the way to negotiate capabilities and can separate the metadata from payload. Nothing revolutionary, but it lets you move forward without hurting existing applications. Isn’t that an upgrade from v3?

>
> 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”.

Why can’t I package this into a single request? Don’t modern web proxies deal with session affinity and stuff like that?

>
> 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?

It does. If Java only had IP, without TCP, would you be able to implement your driver? Yes, but you’d have to suffer longer.

> 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.
>

It’s just framing. But standard framing.

>
> 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 <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”.

What of having that in one single request?

>
> 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.

What does your business app do with the data?

>
> Vladimir