使用する引数が異るのであれば、同じ名前の関数を定義することができます。 つまり、関数名は オーバーロードが可能です。 関数は同じ属性に同じ名前を持つこともできます。複合型の関数と 複合型の属性とであいまいさが存在する場合は、必ず属性が使用されます。
Postgres7.0から、SQLの CREATE FUNCTIONのAS句の代替形式は SQL関数名とCソースコードとを分離させています。現在これは 関数のオーバーロードを克服する、推奨されたテクニックです。
C言語で書かれた関数において、CREATE FUNCTIONで 定義されたSQL名は、実際にC言語のコードの関数内で書かれている名前と 等しい必要があります。(また、それはC言語の正しい関数名である必要があります。)
この制約には密接な関係があります。それはつまり、ほとんどの オペレーティングシステムの動的ロードのルーチンには、 異った/等しい関数名を持っている、いくつものシェアードライブラリを 含めることは可能ですが、実際にはそれらを興味深い方法で 継ぎ接ぎにしているということです。例えば、 Postgresに存在している関数名と同じ名前の関数を動的にロードする、と 定義した場合、DEC OSF/1動的ローダーはPostgresに対して、作成された 関数ではなく、Postgres自身の関数を呼び出すように指示します。 したがって、異ったアーキテクチャで自作の関数を呼び出したい場合は C言語の関数名と同じものを使用しないことをお勧めします。
上記の問題を解決するための賢い方法があります。SQL関数名と 同じ関数名を持つことは問題がありませんので、C言語関数を 異った関数名で定義し、また、適切な引数型を使用し、一致する C言語の関数を呼び出す、同じ名前のSQL関数ラッパーを 定義することによって問題を回避することが可能となります。
もう一方の方法としては、動的ロードを使用せずに、自作の関数を バックエンドに静的にリンク付け、その関数を内部関数として 定義する方法です。この場合、関数はすべて明確なC言語名を持つ必要が ありますが、SQL名と同じ名前で定義することができます(引数の型が異る場合のみ)。 この方法は、カスタムな実行バックエンドを準備することによって、 SQLラッパー関数の重複を防ぎます。(6.5以前のバージョンでは、 内部関数はSQL関数名とC言語関数名は同じでなければならないという 制約があったため、このオプションは、バージョン6.5以降から 使用可能となっています。)