Hacking postgres backend process

Hi,

I've been working with Postgres for about a year, so I'm little better than
a newbie with Postgres' internal architecture or its means of getting
tricksy things done. I've experience in Linux working with PostgreSQL 7.3,
stored procedures in PL/pgSQL, and writing specialized shared libraries,
but I'm running up against a "problem-space boundary" conundrum.

My question is this:

"Are there existing projects which hack the postgres backend-process into
doing things which would make a self-respecting DBA faint at the mere
thought?"

My designs are devious so I will only hint at a possible problem-context:

I have a database and a number of functions (call them "functionalities")
which I want my DB users to be able to access by way of SQL or incorporation
in one or another registered PL's. These function(alities) necessitate
calling one or more external processes, with possible long-duration calls or
large result-sets - always with the intention of returning requisite and
correct responses to the postgres framework so it can do its job of giving
the user the results requested.

My understanding is that it's best to design into the DB those things best
done database-wise and do those things non-database in
C/PERL/whatever-have-you. Fortunately, Postgres makes it possible to insert
highly customized "processes" into the execution flow: what isn't entirely
clear are the limitations inherent in the Postgres framework/api.

I would really appreciate enlightenment on these or related issues!

Carl E. McMillin <|};-)>