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

From Vladimir Sitnikov
Subject Re: Proposal: http2 wire format
Date
Msg-id CAB=Je-H2K++w87JnLbO0u_Paut0NbLHcAQSovpHTVyrW15x=cA@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: http2 wire format  (Damir Simunic <damir.simunic@wa-research.ch>)
Responses Re: Proposal: http2 wire format  (Damir Simunic <damir.simunic@wa-research.ch>)
List pgsql-hackers
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.

When I say GRPC, I mean "implement PostgreSQL-specific protocol via GRPC messages".

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.


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.
Is "curl as PostgreSQL client" one of the key objectives for you?
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.
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

pgsql-hackers by date:

Previous
From: Nikita Glukhov
Date:
Subject: Re: [PATCH] Add missing type conversion functions for PL/Python
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] MERGE SQL Statement for PG11