Re: question about HTTP API

On Fri, Aug 9, 2013 at 9:21 AM, Andrew Tipton <andrew(at)kiwidrew(dot)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