> ...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:[EMAIL PROTECTED] Sent: Tuesday, May 04, 2004 6:29 AM To: Carl E. McMillin Cc: [EMAIL PROTECTED]; 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) ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
