Re: PostgreSQL as an application server - Mailing list pgsql-hackers

From J. Andrew Rogers
Subject Re: PostgreSQL as an application server
Date
Msg-id 1091811646.12329.22.camel@vulture.corp.neopolitan.com
Whole thread Raw
In response to PostgreSQL as an application server  ("Jonathan M. Gardner" <jgardner@jonathangardner.net>)
Responses Re: PostgreSQL as an application server  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: PostgreSQL as an application server  ("Jonathan M. Gardner" <jgardner@jonathangardner.net>)
List pgsql-hackers
On Thu, 2004-08-05 at 22:27, Jonathan M. Gardner wrote:
> A few nights ago, I implemented some of my application logic in PostgreSQL 
> via PL/PythonU. I was simply amazed at what I was able to do. My question 
> becomes: Why not get rid of the middle layer and move it into the databse 
> entirely?


In the mid-90s, I was a lead on just such an app using Oracle PL/SQL. 
IIRC, it was about a half million lines of code.  At that time, Oracle
hadn't seen anything quite like it and was pretty interested in what
we'd done.  I'll add that if we knew what it would be like when we
started, we probably would have done it somewhat differently than we
did.

The advantage is that you have very tight integration with the database
and there are few or no external dependencies to worry about.  For
database heavy applications that require some level of portability, this
isn't a bad way to do development.

The major disadvantage is that the development environment and tools for
in-database languages aren't nearly as rich as your typical standalone
environment, which makes programming a pain in the ass for many types of
codes.  I might have missed something in the intervening years, but I
don't think anyone has really bridged that gap.  The database guys
generally don't like running application code in their database, mostly
because it creates new failure modes and problems that they have to
manage.  For example, at least in older versions of Oracle, if you
accidentally programmed an infinite loop or some other busy
non-functioning state, it took the DBA to kill it.  In the course of
application development, this could happen many, many times as code was
being debugged, much to the annoyance of the DBAs.

That said, I don't see any obvious reason why it couldn't be done well
with a moderate amount of effort.


j. andrew rogers




pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Uncommenting .conf WAS: Open items
Next
From: Tom Lane
Date:
Subject: Re: Uncommenting .conf WAS: Open items