After you have created and registered a user-defined function,
your work is essentially done. Postgres, however, must load the object code
(e.g., a .o file, or a shared library)
that implements your function. As previously mentioned,
Postgres loads your code at
runtime, as required. In order to allow your code to be dynamically
loaded, you may have to compile and link-edit it in a special way.
This section briefly describes how to perform the compilation and
link-editing required before you can load your user-defined
functions into a running Postgres
server. Note that this process has changed as of Version 4.2.

Tip: The old Postgres
dynamic loading mechanism required in-depth knowledge in terms of
executable format, placement and alignment of executable
instructions within memory, etc. on the part of the person
writing the dynamic loader. Such loaders tended to be slow and
buggy. As of Version 4.2, the Postgres dynamic loading mechanism has been
rewritten to use the dynamic loading mechanism provided by the
operating system. This approach is generally faster, more
reliable and more portable than our previous dynamic loading
mechanism. The reason for this is that nearly all modern versions
of UNIX use a dynamic loading mechanism to implement shared
libraries and must therefore provide a fast and reliable
mechanism. On the other hand, the object file must be
postprocessed a bit before it can be loaded into Postgres. We hope that the large increase in
speed and reliability will make up for the slight decrease in
convenience.

You should expect to read (and reread, and re-reread)
the manual pages for the C compiler, cc(1), and the link editor,
ld(1), if you have specific questions. In addition, the regression
test suites in the directory PGROOT/src/regress contain several working examples
of this process. If you copy what these tests do, you should not
have any problems. The following terminology will be used below:

Dynamic loading is what
Postgres does to an object
file. The object file is copied into the running Postgres server and the functions and
variables within the file are made available to the functions
within the Postgres process.
Postgres does this using the
dynamic loading mechanism provided by the operating system.

Loading and link editing is what
you do to an object file in order to produce another kind of
object file (e.g., an executable program or a shared library).
You perform this using the link editing program, ld(1).

The following general restrictions and notes also apply to the
discussion below:

Paths given to the create function command must be absolute
paths (i.e., start with "/") that refer to directories visible
on the machine on which the Postgres server is running.

Tip: Relative paths do in fact work, but are
relative to the directory where the database resides (which
is generally invisible to the frontend application).
Obviously, it makes no sense to make the path relative to the
directory in which the user started the frontend application,
since the server could be running on a completely different
machine!

The Postgres user must be
able to traverse the path given to the create function command
and be able to read the object file. This is because the
Postgres server runs as the
Postgres user, not as the user
who starts up the frontend process. (Making the file or a
higher-level directory unreadable and/or unexecutable by the
"postgres" user is an extremely common mistake.)

Symbol names defined within object files must not conflict
with each other or with symbols defined in Postgres.

The GNU C compiler usually does not provide the special
options that are required to use the operating system's dynamic
loader interface. In such cases, the C compiler that comes with
the operating system must be used.

It is very easy to build dynamically-loaded object files under
ULTRIX. ULTRIX does not have any shared library mechanism and hence
does not place any restrictions on the dynamic loader interface. On
the other hand, we had to (re)write a non-portable dynamic loader
ourselves and could not use true shared libraries. Under ULTRIX,
the only restriction is that you must produce each object file with
the option -G 0. (Notice that that's the numeral ``0'' and not the
letter ``O''). For example,

# simple ULTRIX example
% cc -G 0 -c foo.c

produces an object file called foo.o that can then be
dynamically loaded into Postgres.
No additional loading or link-editing must be performed.