Bill makes several valid points, but in spite of them, the app I'm
writing has almost no logic in the database.
Why? Well, mostly because it would be too much trouble to remove all
of it. :) No, seriously...
Lack of a good language. Postgresql understands a growing number of
languages and that's great, but most business applications (the
dominant type of application when discussing security issues) are
written in an object oriented language like Java or C# (please don't
be offended if I've missed anyone's favourite over-10%-of-the-market
OO language).
pljava is becoming an alternative, but it's still kind of early to
tell if VM-executed languages behave well in a database environment.
It's hard to wri...maintain, maintain anything non-trivial written in
plpgsql: I face that exact problem right now with a couple of fairly
complex import scripts.
Lack of a good IDE. I've yet to hear how I can debug a plpgsql
script/function. If it's just a matter of ignorance, someone please
enlighten me.
Code version control. Yes, you can dump a pgsql database schema
without the actual data and store it in a repository somewhere, but a)
you basically version-control a single large file and b) at least some
other manistream RDBMSes (MSSQL, for one) can't make that kind of dump
(easily), so the potential user base is much reduced and best
(workable?) patterns and practices haven't been established.
On the other hand, writing application logic (which includes security)
in the application isn't at all that bad. Modular design really helps
there: containing the logic in a package/library/module/whatever goes
a long way to allow trivial or very easy reuse in a second or third
app.
And if what you want is a truly heterogeneous application ecosystem
built around the same application logic, you can always go the SOA and
WS way: "hey, you want to code a GUI in RoR? Here you go..." At that
point, you can basically extend your system which ever way you want.
...or at least so I've heard during my knitting class. :)
t.n.a.