Martha Stewart called it a Good Thing when "Carlo Stonebanks" <cstonebanks@nissenfasteners.com> wrote:
> I am interested in finding out a "non-religious" answer to which
> procedural language has the richest and most robust implementation
> for Postgres. C is at the bottom of my list because of how much
> damage runaway code can cause. I also would like a solution which is
> platorm-independent; we develop on Windows but may deploy on Linux.
You mean for implementing stored procedures?
I'd say that the answer varies depending on what the stored proc is
for.
- If it needs to do "text munging," then one of {Perl|Python|Tcl} seem
appropriate; they draw in big libraries of text munging code
- If you're writing code that selects data from various tables based
on the inputs, then pl/pgsql tends to be the natural answer
- C is needed when you need deep engine access that can't be gotten
any other way
- Untrusted Perl/Tcl are nifty if you need access to the rich sets of
external libraries
- If you have some code in Java that you'd want to run in the DB
server, then one of the pl/Java systems may be for you
It doesn't seem overly flameworthy to me.
Except for the cases where you *must* use C, you can usually
accomplish things in the "wrong" language, but there are likely to be
drawbacks...
- Doing funky string munging using the SQL functions available in
pl/pgsql is likely to be painful;
- Doing a lot of DB manipulation in pl/Perl or pl/Tcl or such
requires having an extra level of function manipulations that
won't be as natural as straight pl/pgsql.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','gmail.com').
http://linuxdatabases.info/info/postgresql.html
Q: Are the SETQ expressions used only for numerics?
A: No, they can also be used with symbolics (Fig.18).
-- Ken Tracton, Programmer's Guide to Lisp, page 17.
