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.
