PostgreSQL as an application server - Mailing list pgsql-hackers

From Jonathan M. Gardner
Subject PostgreSQL as an application server
Date
Msg-id 200408052227.08161.jgardner@jonathangardner.net
Whole thread Raw
Responses Re: PostgreSQL as an application server  (David Garamond <lists@zara.6.isreserved.com>)
Re: PostgreSQL as an application server  (Ned Lilly <ned@nedscape.com>)
Re: PostgreSQL as an application server  ("J. Andrew Rogers" <jrogers@neopolitan.com>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Consider this. Most (well-written) applications are written in three
layers. The data abstraction layer provides a clean interface to the
underlying data so other people don't have to write SQL statements. The
GUI layer handles all the GUI events and translates them into function
calls or attribute modifications. Then the layer in between coordinates
the two and often handles more complicated business rules.

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?

The GUI layer would then merely connect to the database and just connect
user actions to actions in the database, and then suck all the data it
needs disrectly from the databsae with a simple interface. Think SOAP,
but where the SOAP server is on the PostgreSQL, and without all the nasty
overhead.

The layer on top of the database would provide proxy objects that the GUI
could access and modify. These accesses and modifications are translated
into accesses and modifications of the objects underneath. All the
business logic is stored in the database server.

Thoughts? Comments? Hasn't Oracle done something like this?

- --
Jonathan Gardner
jgardner@jonathangardner.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFBExaqqp6r/MVGlwwRAtcTAJ4xXmWFyGWOT0s7gyc9yyr2VtYYtwCeMSbH
5eMhuRiyyB6oVDaLIcdRA64=
=tcLi
-----END PGP SIGNATURE-----


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: pgxs: build infrastructure for extensions v4
Next
From: Tom Lane
Date:
Subject: Re: Upgrade path for contrib modules