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