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
