Proposal to expose PgClient functionality through R2DBC API

R2DBC is an initiative to establish a common SPI for relational database drivers embracing reactive programming properties: Event-oriented, non-blocking, and ideally stream-oriented access to databases. R2DBC is built entirely on Reactive Streams defining a minimal API surface to be implemented by drivers without the need to re-implement common client functionality in every driver.

From an R2DBC perspective there are a couple of interfaces that could be implemented by using the following components of PgClient:

• ConnectionFactory -> PgClient and PgPool
• Connection -> PgConnection
• Statement -> Utility to build/prepare a statement, eventually calling PgConnection.query(…) or PgConnection.preparedQuery(…) methods
• Result -> PgRowSet
• Row -> (Pg) Row

What is the benefit of doing so?

Benefits:

• Following an API that is well-suited for client developers without the need to entirely change how the client is supposed to work
• Participating in a growing client-ecosystem (MyBatis, draft, JDBI, Spring) with clients providing a humane API. Application developers get a choice of which client they want to use for specific use-cases.
• With the choice of clients, PgClient isn't required to provide additional functionality such as object mapping or SQL generation. That's up to the client.
• Choice of plug and play for a growing eco-system of drivers beyond Postgres and MySQL (e.g. H2, Microsoft SQL Server) that can be used with vert.x.

Drawbacks:

• https://xkcd.com/927/
• Dependency on Reactive Streams (could be optional, still)
• Additional complexity by maintaining two driver frontends

Related ticket: #245.

Comience revisando las API existentes de PgClient, PgPool, PgConnection, PgRowSet y Row mencionadas en la propuesta y, a continuación, compárelas con las interfaces ConnectionFactory, Connection, Statement, Result y Row de R2DBC. El issue no identifica archivos, pruebas ni un alcance acordado; un siguiente paso útil es definir la superficie de la API y los criterios de aceptación antes de la implementación.