Re: Proposal: http2 wire format

On Mon, Mar 26, 2018 at 1:05 PM, Damir Simunic <damir(dot)simunic(at)wa-research(dot)ch
> wrote:

> 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?
>

​Is content negotiation - beyond client/server character encoding -
something we want the server to be capable of performing? My gut reaction
is no.

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

​How large a problem/benefit is this overall? We are choosing between
standard-but-new versus specialized-but-widely-implemented. While the v3
protocol is a sunk cost there must be considerable value in incrementing it
20% to get to better place rather than starting over from scratch with a
general-purpose, and I suspect more verbose, protocol.

I admire the vision presented here but I do wonder whether its asking
PostgreSQL to be more than it is reasonably capable of being? Presently
the architectures I'm aware of have clients talk to middleware application
servers, running DB drivers, talking to PostgreSQL clusters. This vision
wants to remove the middleware application server and allow clients to
directly communicate with the server in client-native protocols and formats
(http and json). That adds a considerable amount of responsibility to
PostgreSQL that it does not presently have and, having observed the
community for a number of years now and seeing the responses on this
thread, is responsibility it probably should not be given. Let those
concerns reside in the middleware under the control of developers -
potentially through frameworks such as PostGraphile [1] and the like.

Or a fork - one that can choose to operate different and/or more frequent
release cycle than the annual one that PostgreSQL uses.

David J.

[1] https://github.com/graphile/postgraphile