Se puede definir m�s de una funci�n con el mismo nombre, siempre que los argumentos que tomen sean diferentes. En otras palabras, los nombres de las funciones se pueden sobrecargar. Una funci�n puede tener adem�s el mismo nombre que un atributo. En el caso de que haya ambig�edad entre una funci�n sobre un tipo complejo y un atributo del tipo complejo, se usar� siempre el atributo.
A partir de Postgres v6.6, la forma alternativa de la cl�usula AS para la orden de SQL CREATE FUNCTION desempareja el nombre de la funci�n SQL del nombre de funci�n en el c�digo fuente C. Esta es ahora la t�cnica preferida para realizar la sobrecarga de funciones.
Para funciones escritas en C, el nombre SQL declarado en CREATE FUNCTION debe ser exactamente el mismo que el nombre real de la funci�n en el c�digo C (debido a esto debe ser un nombre de funci�n de C legal).
Hay una sutil consecuencia de este restricci�n: mientras las rutinas de carga din�micas en la mayor�a de los sistemas operativos est�n mas que felices de permitirle cargar cualquier n�mero de librer�as compartidas que contienen nombres de funciones conflictivos (con id�nticos nombres), pueden, de hecho, chapucear la carga de formas interesantes. Por ejemplo, si usted define una funci�n din�micamente cargada que resulta tener el mismo nombre que una funci�n perteneciente a Postgres, el cargador DEC OSF/1 din�mico hace que Postgres llame a la funci�n dentro de �l mismo preferiblemente a dejar que Postgres llame a su funci�n. Por esto, si quiere que su funci�n se use en diferentes arquitecturas, recomendamos que no sobrecargue los nombres de las funciones C.
Hay un truco ingenioso para resolver el problema que se acaba de describir. Dado que no hay problemas al sobrecargar funciones SQL, usted puede definir un conjunto de funciones C con nombres diferentes y entonces definir un conjunto de funciones SQL con id�nticos nombres que tomen los tipos de argumentos apropiados y llamen a la funci�n C correspondiente.
Otra soluci�n es no usar la carga din�mica, sino enlazar sus funciones al backend st�ticamente y declararlas como funciones INTERNAL. Entonces, las funciones deben tener todas nombres C distintos pero se pueden declarar con los mismos nombres SQL (siempre que los tipos de sus argumentos difieran, por supuesto). Esta forma evita la sobrecarga de una funci�n wrapper (o envolvente) SQL, con la desventaja de un mayor esfuerzo para preparar un ejecutable del backend a medida. (Esta opci�n est� disponible s�lo en la versi�n 6.5 y posteriores, dado que las versiones anteriores requer�an funciones internas para tener el mismo nombre en SQL que en el c�digo C.)