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 <|};-)>
