Hi All,
I posted this subject on General discussion-list but got no takers. I'll restate my query and be as brief as I possible.
"What are the issues/dangers involved in putting an external process-execution call in instance of main postgres-backend thread of execution?"
The operating context will be a Linux/UNIX OS.
Here is a typical SQL statement I'm trying to field: "SELECT * FROM f(a)."
Where "f" is a stored-procedure stub to a shared library C function,
"a" is a string-parameter.
"f" will need to - under the proper circumstances - call an external process "p", parse the process-output, and return a set of structured records.
"p" may run for a very long time; may cause SIG_*; may leave heap in an inconsistent state; may spawn child-processes.
I've already written a number of stored-procedures backed by shared libraries implemented in C, including set-returning functions, and I know the basics of user-types and arrays (including some custom array extensions). I've written UNIX shell processes in C while in school, so I know a bit about child-process control and signal-handling.
It seems that "fork" is clearly out; I'm assuming process execution environment MUST be guaranteed consistent on re-entrance into postgres. Using "exec" is possibly worse with a full image-overlay destroying any hope of reconstructing pre-spawn environment. What are my options here?
Thanks for any input,
Carl <|};-)>
