Re: Proposal: http2 wire format

> On 26 Mar 2018, at 18:09, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> wrote:
>
> Damir>Postgres doesn’t know about grpc, s
>
> I'm afraid you are missing the point.
> I would say PostgreSQL doesn't know about HTTP/2.
> It is the same as "PostgreSQL doesn't know about grpc".
>
> Here's a quote from your pg_h2 repo:
> >What we need is to really build a request object and correctly extract
> > the full payload and parameters from the request. For example,
> >maybe we want to implement a QUERY method, similar to POST or PUT,
> > and pass the query text as the body of the request, with parameters
> > in the query string or in the headers
>
> It basically suggests to implement own framing on top of HTTP/2.

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

>
> When I say GRPC, I mean "implement PostgreSQL-specific protocol via GRPC messages".
>
> Let's take current message formats: https://www.postgresql.org/docs/current/static/protocol-message-formats.html
> If one defines those message formats via GRPC, then GRPC would autogenerate parsers and serializers for lots of languages "for free".
>
> For instance
> Query (F)
> Byte1('Q') Identifies the message as a simple query.
> Int32 Length of message contents in bytes, including self.
> String The query string itself.
>
> can be defined via GPRC as
> message Query {
> string queryText = 1;
> }
>
> This is trivial to read, trivial to write, trivial to maintain, and it automatically generates parsers/generators for lots of languages.
>

I agree with you 100% here. But can you pull off grpc without HTTP2 framing in place? Would it be the only protocol supported? What if I wanted JSON or CSV returned, or just plain old Postgres v3 binary format, since I already have the parser written for it? Wouldn’t you need to first solve the problem of content negotiation?

HTTP2 proposal is pragmatically much smaller chunk, and it’s already hard to explain. Can you imagine the reaction and discussion if I came up with this?

In fact, if you ask yourself the question “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?

>
> Parsing of the current v3 protocol has to be reimplemented for each and every language, and it would be pain to implement parsing for v4.
> Are you going to create "http/2" clients for Java, C#, Ruby, Swift, Dart, etc, etc?
>
> I am not saying that a mere redefinition of v3 messages as GRPC would do the trick. I am saying that you'd better consider frameworks that would enable transparent implementation of client libraries.
>
> Damir>and will talk to any HTTP2 conforming client
>
> I do not see where are you heading to.

Getting rid of having to write a framing parser in every client language?

> Is "curl as PostgreSQL client" one of the key objectives for you?

No, it’s just something that is available right now—the point is to demonstrate increased ability to get the data out, without having to write access code over and over, and then lug that whenever you install some data processing piece. Kind of the same motivation why you think grpc is it. I’m just proposing a layer under it that gets rid of a lot of pain.

> True clients (the ones that are used by the majority of applications) should support things like "prepared statements", "data types", "cursors" (resultset streaming), etc. I can hardly imagine a case when one would use "curl" and operate with prepared statements.

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

> I think psql is pretty good client, so I see no point in implementing HTTP/2 for a mere reason of using curl to fetch data from the DB.

>
> Vladimir