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.
