On Fri, Aug 9, 2013 at 9:21 AM, Andrew Tipton <span dir="ltr"><<a href="mailto:andrew@kiwidrew.com"
target="_blank">andrew@kiwidrew.com</a>></span>wrote:<br /><div class="gmail_quote"><blockquote class="gmail_quote"
style="margin:00 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I recently threw together a quick-and-dirty
prototypeof this idea. It was an external tool which used the libmicrohttpd library to accept incoming requests,
convertthem to a SQL query (which called a stored procedure), and return the query results. (It allowed *any*
content-typeto be returned, not just JSON.) I only got as far as handling GET requests. The code is available
here:</blockquote></div><br/>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?<br /><br />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
cutsbecause they know there will be no more operations in the transaction aside from commit or rollback.<br /><br />A
decentHTTP RPC layer will need to have some way of creating a session and issuing multiple requests on that session.
Thatsession 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
interfacethe performance issues of not having a relcache built will be pretty severe.<br /><br />I suspect this is
somethingbetter built into something like pgbouncer which already has to deal with multiplexing many clients onto a
singleconnection. <br /><br clear="all" /><br />-- <br />greg<br />
