pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Craig Ringer <ringerc@ringerc.id.au>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Andreas Joseph Krogh <andreak@officenet.no>
Cc: pgsql-general@postgresql.org
Subject: Re: Using Postgresql as application server
Date: Tue, 16 Aug 2011 08:06:22 +0800
Message-ID: <4E49B47E.8020401@ringerc.id.au> (raw)
In-Reply-To: <CAHyXU0xQp+-sA6-oPJVTYaFBYO_R4P=fnX+jm8Pgy_j0rPcO7Q@mail.gmail.com>
References: <CAN2Y=uPjF14F5A9JXj02_vaPw4TMR0WGQid_w80xt4sC8o4qGg@mail.gmail.com>
	<4E46D0D7.3090700@officenet.no>
	<CAHyXU0xQp+-sA6-oPJVTYaFBYO_R4P=fnX+jm8Pgy_j0rPcO7Q@mail.gmail.com>

On 15/08/2011 10:36 PM, Merlin Moncure wrote:
> On Sat, Aug 13, 2011 at 2:30 PM, Andreas Joseph Krogh
> <andreak@officenet.no>  wrote:
>> No, PG has never, and will never, act as an application-server.
> Why in the world not?

The biggest reason is safety. Beyond that, the lack of autonomous 
transactions, stored procedures, in-DB timers, and support for any 
protocol other than the native Pg database query protocol mean it's also 
rather impractical.

I guess theoretically one could embed a JVM / Python instance / whatever 
in the postmaster and have it spawn new backends for incoming 
connections with other protocols. But ... why? Why add all that 
complexity and - more importantly - contaiminate PostgreSQL's address 
space with more code that can fail when you don't have to? PLs and user 
C procedures are already risk enough as far as I'm concerned.

I *like* the DB being standalone. It's safer from bad code scribbling 
garbage across the heap and corrupting shared memory.

What do you gain by trying to make Pg play appserver too?

Now, I have nothing against keeping business logic in the DB. This makes 
a lot of sense to me, though it'd be better if it were easier to version 
DB changes. What I don't get is having the client access front-end in 
the DB too ... that just seems like asking for trouble and security 
problems.

> 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.
Actually, I'd say Oracle's really solid Java support, in-db timers, and 
autonomous transactions makes it rather better suited.

--
Craig Ringer



view thread (88+ messages)  latest in thread

Message-ID: <4E49B47E.8020401@ringerc.id.au>
Permalink:  ../4E49B47E.8020401@ringerc.id.au/
Also on:    postgresql.org/message-id/4E49B47E.8020401@ringerc.id.au

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: ringerc@ringerc.id.au, mmoncure@gmail.com, andreak@officenet.no, pgsql-general@postgresql.org
  Subject: Re: Using Postgresql as application server
  In-Reply-To: <4E49B47E.8020401@ringerc.id.au>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox