The wire protocol is the language spoken between a client and the server of postgresql. The majority of programming languages out there do not implement their own version of the protocol instead opting to bind to the C library libpq. There are notable exceptions, specifically C# and Java both of which implement native versions of the wire protocol for their respective languages.

The current wire protcol is v4 and was developed for 7.4 of PostgreSQL. That was released in 2003. I think we can safely say there is a lot of new thinking and things we want to change in the protocol to bring it up to newer thoughts on performance and features. A list of which can be found here:

https://wiki.postgresql.org/wiki/Todo#Wire_Protocol_Changes

One of them is particularly entertaining: Use Commpression. We had a patch for using compression on the wire protocol many years ago and we were essentially told there wasn't a use case. Funny how things change over time. That is the way of the community (replication now in core, cough cough) and we love it for it. The community is relatively conservative and because of that we have arguably the most stable and feature rich RDMS of it.

An item I suggested was the ability for the wire protocol to understand the type of connection that was being requested. In short I want the ability to tell a connection that it is a read-write, read-only or write-only connection. In practice a read-only connection would work something like this:

conn-r = psycopg2.connect(database='testdb', user='test', conn-type='r')

I think this would be particularly useful to a tool such as pgPool-II. PgPool-II is a sophisticated software that supports replication, load balancing and query caching. Although we only use it for load balancing, which it is very good at.

The problem is, it is relatively slow. It is slow because it has to parse each query that is executed to determine what to do with it. If it is a SELECT only then it can be load balanced. Again, it works well but if pgPool-II knew from the get go the type of connection it was dealing with because the protocol told it on negotiation then it wouldn't need to parse the query because the query was called on the conn-type='r' handle.

I could see it also being useful in the future if we were to get load balancing into core. The connection receiving postmaster would see that it is a read-only connection and automatically pass it a replication slave.

To see more of what is being discussed you can review the thread.