On Mon, Aug 15, 2011 at 5:14 PM, David Johnston <polobo@xxxxxxxxx> wrote: >> This whole line is getting somewhat off-topic; we're not talking about a "computationally complete" application but simply one that can handle HTTP requests and dispatch calls to user-defined methods. This seems like a small-enough requirement and seems to already have a solution (though I haven't looked at the provided links); whether you call it PostgreSQL or not is a matter of semantics (as is much of this thead).<< Which PostgreSQL *can* do, but probably shouldn't. >> Please restate your request in terms of benefits as opposed to checklist of cool features that barely work but, because they are present, can be added to the marketing materials.<< The whole thing is: Pg as an app server occupies a *different* role than a traditional app server. Not better or worse, just different. Think of it as a database program which can also operate as a message queue once operations complete successfully and committed. That's a pretty powerful thing with listen/notify. And you can process data in additional PL's as well, accessing methods from other languages so you don't have to reinvent the wheel. It is my view that PostgreSQL makes an *excellent* application server as long as you use it intelligently. That means treating the database as the *central* application and then using it to manage not only main data storage, but also message queues to other helper processes which can, for example, send email, print documents, or whatever. This is the direction LedgerSMB is moving: using Pg to the max but doing so carefully and intelligently. It is not a traditional application server, but it can easily replace a traditional application server along with helper programs in whatever languages one wants to write them in. The power and flexibility is really quite amazing. Best Wishes, Chris Travers -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
