他のバージョンの文書 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

9.6. 関数のオーバライド

使用する引数が異なるのであれば、同じSQL名の関数を定義することができます。つまり、関数名はオーバーロードが可能です。問い合わせが実行された時、サーバはデータ型と与えられた引数の数によって呼び出すべき関数を決定します。引数の数が可変で、最大が無限である、simulate 関数をオーバライドすることもできます。

関数は属性と同じ名前を持つこともできます。複合型の関数と複合型の属性とであいまいさが存在する場合は、必ず属性が使用されます。 オーバロードされた関数群を作成する時、曖昧さが発生しないように注意しなければなりません。

例えば、以下のような関数を考えると、test(1, 1.5) のようなtrivialな入力ではどちらの関数を呼び出すのかは明確ではありません。

CREATE FUNCTION test(int, real) RETURNS ...
CREATE FUNCTION test(smallint, double precision) RETURNS ...

現在実装されている解決規則は ユーザガイドにて説明していますが、この動作にsubtlyに依存するようにシステムを設計することは推奨しません。

C 言語関数をオーバロードする場合、更に制限があります。オーバロードされた関数群内の各関数の C の名前は、内部か動的ロード可能かに関係なく他の全ての関数の C の名前と異なる必要があります。この規則に反した場合は、この動作は移植性がありません。実行時リンカエラーになるかもしれませんし、関数群のどれか(大抵は内部関数)が呼び出されるかもしれません。CREATE FUNCTION コマンドの AS 句の別形式は、SQL 関数名と C ソースコード内の関数名とを分離します。以下に例を示します。

CREATE FUNCTION test(int) RETURNS int
    AS 'filename', 'test_1arg'
    LANGUAGE C;
CREATE FUNCTION test(int, int) RETURNS int
    AS 'filename', 'test_2arg'
    LANGUAGE C;

ここでの C関数の名前は多くの取り得る規約の1つを反映しています。

PostgreSQL 7.0 以前では、この別形式の構文はありませんでした。異なる名前で C 関数の集合を定義し、そして、適切な引数型をとり、対応する C 関数を呼び出す、SQL 関数名と同じラッパ関数の集合を定義するという、この問題を回避するためのトリックがあります。