On Fri, Aug 9, 2013 at 9:21 AM, Andrew Tipton
<andrew@kiwidrew.com> wrote:
I recently threw together a quick-and-dirty prototype of this idea. It was an external tool which used the libmicrohttpd library to accept incoming requests, convert them to a SQL query (which called a stored procedure), and return the query results. (It allowed *any* content-type to be returned, not just JSON.) I only got as far as handling GET requests. The code is available here:
I looked at the wiki and thought it had a lot of good ideas but also a lot of good questions. do you have any idea how to tackle the session problem?
Postgres has always assumed session == backend == connection. TPC prepared transactions are the one main break in this model and they can take a lot of short cuts because they know there will be no more operations in the transaction aside from commit or rollback.
A decent HTTP RPC layer will need to have some way of creating a session and issuing multiple requests on that session. That session will need to be a stored and available for future requests. The obvious concern is state like the current database, current role, gucs, and prepared queries. But even if you're prepared to discard those for a stateless interface the performance issues of not having a relcache built will be pretty severe.
I suspect this is something better built into something like pgbouncer which already has to deal with multiplexing many clients onto a single connection.
--
greg
