On Fri, Aug 9, 2013 at 9:21 AM, Andrew Tipton <and...@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
