> ...Basically if you are in constant fear you are in the
> right shift of mind to do it ... check every return code,
> make sure you don't write unassigned memory, make sure the
> function wears its mithril shirt at all times, etc.
Hehe! Thanks for the warning. Do you know of anyone that's managed to
successfully work these control-structures in with the C api? I've heard
some good words apropos PL/Perl to control external processes, but I've also
heard there are notable limitations (say absence) with set-returning
functions in PL/Perl (tho perhaps under construction).
Carl <|};-)>
-----Original Message-----
From: Alvaro Herrera [mailto:alvherre@dcc.uchile.cl]
Sent: Tuesday, May 04, 2004 6:29 AM
To: Carl E. McMillin
Cc: pgsql-hackers@postgresql.org; Bob
Subject: Re: [HACKERS] Hacking postgres backend process
On Wed, Apr 28, 2004 at 08:26:09AM -0700, Carl E. McMillin wrote:
> 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?"
I'm not sure of all the issues it has, but as you probably already know, a C
function has access to anything inside the server process. This means it
can corrupt private structures, look memory and data bypassing privileges,
etc; and if you get an uncaught SIGSEGV the backend will die and the
postmaster will terminate all running backends. Basically if you are in
constant fear you are in the right shift of mind to do it ... check every
return code, make sure you don't write unassigned memory, make sure the
function wears its mithril shirt at all times, etc.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"If it wasn't for my companion, I believe I'd be having
the time of my life" (John Dunbar)