Resent-From: POSTGRES mailing list <postman@postgres.Berkeley.EDU>
Resent-Message-Id: <199408251930.MAA26382@nobozo.CS.Berkeley.EDU>
Sender: owner-postman@postgres.Berkeley.EDU
Message-Id: <199408251929.MAA25215@faerie.CS.Berkeley.EDU>
From: aoki@cs.berkeley.edu (Paul M. Aoki)
To: N B Idris <Norbik.B.Idris@cm.cf.ac.uk>
Cc: postgres@postgres.Berkeley.EDU
Subject: Re: C functions 
Reply-To: aoki@cs.berkeley.edu (Paul M. Aoki)
In-reply-to: Your message of Thu, 25 Aug 94 19:50:18 BST 
	     <9408251850.AA07744@diamond.cm.cf.ac.uk> 
Date: Thu, 25 Aug 94 12:29:21 -0700
Resent-To: postgres-redist@postgres.Berkeley.EDU
Resent-Date: Thu, 25 Aug 94 12:30:07 -0700
Resent-XMts: smtp

N B Idris <Norbik.B.Idris@cm.cf.ac.uk> writes:
> In writing a user defined C function which is callable via a define
> function command, can we have within the C function :
> 	a) Basic I/O functions such as scanf/printf?

sure, but the input/output are generally connected to /dev/null.

(think about it.  the backend server is running on some machine X.
your frontend program is (in general) running on some machine Y..)

if you need a message printed to the user process, include
"utils/log.h" and do something like:
	elog(NOTICE, "hello world from server process %d", getpid());

you can also redirect the standard output of the backends to a file or
tty using the backend's -o option, which can be set using the
postmaster's -o option, using something like:
	postmaster -o '-o /dev/ttyp2'

> 	b) System calls eg. system("shelltool routine2");
> 	   where parameter "routine2" is another executable program to be 
> 	   invoked within the new shelltool called?

first, system(3) starts /bin/sh.  if either "shelltool" or "routine2"
is not in the default path then the call won't work.

so now, just for the sake of argument, say you use:
	system("/bin/shelltool /what/ever/the/path/is/routine2");
the old suntools routines would only work on the local machine and
would require a bunch of stupid environment variables (like WINDOWID)
to be set.  if the "postgres" user that started the postmaster did not
have the right environment (i.e., it was not started by you during
this login session), then shelltool can't start.  (remember, *you*
aren't starting up the backend process with your shell as the parent
process.  the "postgres" user is, and in fact, the postmaster started
by some random person during some random login session is the parent
process.  hence the environment will not generally be right.  fixing
this is specific to your user environment..)

now, say you use X11.  the server is running as "postgres" on machine
X. you are running as you on machine Y.  if X != Y, and you are using
xhost(1), then you will have a problem.  if you are using XAUTHORITY,
you have a bigger problem.

btw, both of these issues (i.e., correct search paths for subprocesses
and correct environments/permissions for window system processes) are
completely orthogonal from postgres.  any server (postgres, ftpd)
started by some daemon process (postmaster, inetd) would face the same
issues.  your local system gurus would probably be more help than
anyone on this mailing list..
--
  Paul M. Aoki          |  University of California at Berkeley
  aoki@CS.Berkeley.EDU  |  Dept. of EECS, Computer Science Division (#1776) 
                        |  Berkeley, CA 94720-1776

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU"

   If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================