More than one function may be defined with the same name, so
long as the arguments they take are different. In other words,
function names can be overloaded. A
function may also have the same name as an attribute. In the case
that there is an ambiguity between a function on a complex type
and an attribute of the complex type, the attribute will always
be used.

As of Postgres 7.0, the
alternative form of the AS clause for the SQL CREATE FUNCTION command decouples the SQL
function name from the function name in the C source code. This
is now the preferred technique to accomplish function
overloading.

For functions written in C, the SQL name declared in
CREATE FUNCTION must be exactly the
same as the actual name of the function in the C code (hence
it must be a legal C function name).

There is a subtle implication of this restriction: while
the dynamic loading routines in most operating systems are
more than happy to allow you to load any number of shared
libraries that contain conflicting (identically-named)
function names, they may in fact botch the load in
interesting ways. For example, if you define a
dynamically-loaded function that happens to have the same
name as a function built into Postgres, the DEC OSF/1 dynamic
loader causes Postgres to call the function within itself
rather than allowing Postgres to call your function. Hence,
if you want your function to be used on different
architectures, we recommend that you do not overload C
function names.

There is a clever trick to get around the problem just
described. Since there is no problem overloading SQL
functions, you can define a set of C functions with different
names and then define a set of identically-named SQL function
wrappers that take the appropriate argument types and call
the matching C function.

Another solution is not to use dynamic loading, but to
link your functions into the backend statically and declare
them as INTERNAL functions. Then, the functions must all have
distinct C names but they can be declared with the same SQL
names (as long as their argument types differ, of course).
This way avoids the overhead of an SQL wrapper function, at
the cost of more effort to prepare a custom backend
executable. (This option is only available in version 6.5 and
later, since prior versions required internal functions to
have the same name in SQL as in the C code.)

Submit correction

If you see anything in the documentation that is not correct, does not match
your experience with the particular feature or requires further clarification,
please use
this form
to report a documentation issue.