Before you are able to use your PostgreSQL extension function written in C they need to be compiled and linked in a special way in order to allow it to be dynamically loaded as needed by the server. To be precise, a shared library needs to be created. For more information you should read the documentation of your operating system, in particular the manual pages for the C compiler, cc, and the link editor, ld. In addition, the PostgreSQL source code contains several working examples in the contrib directory. If you rely on these examples you will make your modules dependent on the availability of the PostgreSQL source code, however. Creating shared libraries is generally analoguous to linking executables: first the source files are compiled into object files, then the object files are linked together. The object files need to be created as position-independent code (PIC), which conceptually means that they can be placed at an arbitrary location in memory when they are loaded by the executable. (Object files intended for executables are not compiled that way.) The command to link a shared library contains special flags to distinguish it from linking an executable. --- At least this is the theory. On some systems the practice is much uglier. In the following examples we assume that your source code is in a file foo.c and we will create an shared library foo.so. The intermediate object file will be called foo.o unless otherwise noted. A shared library can contain more than one object file, but we only use one here. BSD/OS The compiler flag to create PIC is -fpic. The linker flag to create shared libraries is -shared. gcc -fpic -c foo.c ld -shared -o foo.so foo.o This is applicable as of version 4.0 of BSD/OS. FreeBSD The compiler flag to create PIC is -fpic. To create shared libraries the compiler flag is -shared. gcc -fpic -c foo.c gcc -shared -o foo.so foo.o This is applicable as of version 3.0 of FreeBSD. HP-UX The compiler flag of the system compiler to create PIC is +z. When using GCC it's -fpic. The linker flag for shared libraries is -b. So cc +z -c foo.c or gcc -fpic -c foo.c and then ld -b -o foo.sl foo.o HP-UX uses the extension .sl for shared libraries, unlike most other systems. Irix PIC is the default, no special compiler options are necessary. The linker option to produce shared libraries is -shared. cc -c foo.c ld -shared -o foo.so foo.o Linux The compiler flag to create PIC is -fpic. On some platforms in some situations -fPIC must be used if -fpic does not work. Refer to the GCC manual for more information. The compiler flag to create a shared library is -shared. A complete example looks like this: cc -fpic -c foo.c cc -shared -o foo.so foo.o NetBSD The compiler flag to create PIC is -fpic. For ELF systems, the compiler with the flag -shared is used to link shared libraries. On the older non-ELF systems, ld -Bshareable is used. gcc -fpic -c foo.c gcc -shared -o foo.so foo.o OpenBSD The compiler flag to create PIC is -fpic. ld -Bshareable is used to link shared libraries. gcc -fpic -c foo.c ld -Bshareable -o foo.so foo.o Digital Unix/Tru64 UNIX PIC is the default, so the compilation command is the usual one. ld with special options is used to do the linking: cc -c foo.c ld -shared -expect_unresolved '*' -o foo.so foo.o The same procedure is used with GCC instead of the system compiler; no special options are required. Solaris The compiler flag to create PIC is -KPIC with the Sun compiler and -fpic with GCC. To link shared libraries, the compiler option is -G with either compiler or alternatively -shared with GCC. cc -KPIC -c foo.c cc -G -o foo.so foo.o or gcc -fpic -c foo.c gcc -G -o foo.so foo.o Unixware The compiler flag to create PIC is -K PIC with the SCO compiler and -fpic with GCC. To link shared libraries, the compiler option is -G with the SCO compiler and -shared with GCC. cc -K PIC -c foo.c cc -G -o foo.so foo.o or gcc -fpic -c foo.c gcc -shared -o foo.so foo.o If you want to package your extension modules for wide distribution you should consider using GNU Libtool for building shared libraries. It encapsulates the platform differences into a general and powerful interface. Serious packaging also requires considerations about library versioning, symbol resolution methods, and other issues. The resulting shared library file can then be loaded into Postgres. When specifying the file name to the CREATE FUNCTION command, one must give it the name of the shared library file (ending in .so) rather than the simple object file. Actually, Postgres does not care what you name the file as long as it is a shared library file. 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. 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 user id the Postgres server runs as must be able to traverse the path given to the CREATE FUNCTION command and be able to read the shared library file. (Making the file or a higher-level directory not readable and/or not executable by the postgres user is a common mistake.)