On Mon, Aug 15, 2011 at 9:50 AM, Andreas Joseph Krogh <andreak@xxxxxxxxxxxx> wrote: > På mandag 15. august 2011 kl 16:36:23 skrev du: >> On Sat, Aug 13, 2011 at 2:30 PM, Andreas Joseph Krogh >> <andreak@xxxxxxxxxxxx> wrote: >> > No, PG has never, and will never, act as an application-server. >> >> Why in the world not? Now, it may or may not be a good idea but there >> is no technical constraint that prevents postgresql from being used in >> this fashion. I think it's a fine idea. >> >> Postgresql has certain features, in particular being able to implement >> functions in any language, that make it uniquely well suited among its >> peers to act as a application server platform. Having a >> quasi-functional front end to your middeware procedural code is very >> powerful as is having direct access to a local data store for caching >> and spooling purposes. So powerful that I would argue that if >> properly supported by tools it would be superior to many of the more >> classic stacks in use today. I could go down the list of reasons why >> that's the case -- tight coupling with data, performance, emphasis on >> transactional coding, etc. There are downsides too, but those could >> be mitigated with some thought and work. >> >> Postgres is not just a database -- it's a language hosting platform if >> you want to use it as such. Now, you can continue to do things as >> you've always done (database 'here', code 'here', web server 'here'), >> but why discourage people from trying out different things? >> >> merlin > > Sorry if I stepped on any toes here. But seriously - by my definition of app-server PG is not suited at all. I strongly would discourage anyone from using any RDBMS as an app-server. *IMO* it makes development, testing, separation-of-consern, debugging and re-deployment a nightmare. > > PG has a lot of nice DB-features and I use it every day, but as an app-server - no way. Nobody's toes are getting stepped on. Constructive debate gets people talking and puts the issues on the table. Your complaints are pretty non-specific (development is a 'nightmare'...why?). This topic reminds me a lot of the 'is putting logic in functions a good idea?' debate which tends to bring out strong opinions which are light on substance. As I've said many times this debate gets really interesting in the specific case of PostgreSQL because the database is so extensible with good abstractions in the right places. An application server from my point of view is just a server that sits between the UI (typically a browser these days) and the database. This server manages various temporary structures like application state and data spools coming from the 'persistence later' (the database). Due to heavy emphasis on the importance of putting most code into this layer from companies like IBM and Microsoft, we've seen an explosion of tools and libraries that can be hooked in here so that, if you choose to do so, you can drive the entire application stack such that the database and the browser are just appendages of this system. This path is rich, well traveled, and boring. But are we things really being done in the right way? I obviously don't think so...in fact I think the typical corporate IT programming dept is a total disaster. Many programmers, especially those who really get SQL and the relational model tend to resist programming in this fashion because they feel that it's over-complex, verbose (especially in java-land), and brittle. SQL provides a lot of strong guarantees that are relatively easy for even a junior programmer to take advantage of like serializability of action and automatic rollback to a known state due to an unhandled error. Programming around the lack of these features could charitably be described as creating a strong justification for the excellent debugging tools you are mentioning. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
