Re: Proposal: http2 wire format

Поиск
Список
Период
Сортировка
От Vladimir Sitnikov
Тема Re: Proposal: http2 wire format
Дата
Msg-id CAB=Je-H2K++w87JnLbO0u_Paut0NbLHcAQSovpHTVyrW15x=cA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: http2 wire format  (Damir Simunic <damir.simunic@wa-research.ch>)
Ответы Re: Proposal: http2 wire format  (Damir Simunic <damir.simunic@wa-research.ch>)
Список 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 по дате отправления:

Предыдущее
От: Nikita Glukhov
Дата:
Сообщение: Re: [PATCH] Add missing type conversion functions for PL/Python
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [HACKERS] MERGE SQL Statement for PG11