Re: Proposal: http2 wire format

Damir>Wouldn’t that be protocol semantics? Framing is already taken care of
by the wire protocol.

Apparently I'm using the wrong word. I do mean protocol semantics.

Damir>But can you pull off grpc.. Would it be the only protocol supported?

Of course there will be lots of "older clients"
For instance, pgjdbc has been supporting v2 and v3 for quite a while.
Now it supports just v3.

Damir>Can you imagine the reaction and discussion if I came up with this?

I would +1 for that :)

Damir>how can I do something about the status quo of FEBE protocol that
would be defensible in front of the Postgres community?” What would be your
answer?

I would definitely check if frameworks like GRPC, Apache Thrift, and
similar are suitable.

Damir>What if I wanted JSON or CSV returned

That is not up to the protocol. It is not up to the backend.
It looks like a task for the application since CSV could mean lots of stuff
(e.g. commas vs tabs vs quotes etc). You don't want to integrate all that
stuff in core.

Damir>Wouldn’t you need to first solve the problem of content negotiation?

Currently content negotiation is done at application level (e.g. at bind
message). I don't think it makes sense to negotiate the content for each
and every protocol message. It does sound like an over-engineering.

Damir>Wouldn’t HTTP2 framing still allow prepared statements and cursors?

It will require to implement parse/bind/execute "protocol messages" again
and again.

Damir>’m just proposing a layer under it that gets rid of a lot of pain.

The thing is it is not clear whose pain are you treating.
Application developers just use drivers, so they don't care if there's
HTTP/2 under the covers.
Driver developers have more-or-less tested v3 implementations, so they
don't have that pain of "implementing v3 parser".
PostgreSQL core developers ..., well, you know.

Vladimir