

 Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。

# ストアドプロシージャの名前付け
<a name="stored-procedure-naming"></a>

このトピックでは、ストアドプロシージャ名の詳細について説明します。

プロシージャを定義する際に同じ名前を付けて、異なる入力引数のデータ型 (署名) を使用すると、別のプロシージャが作成されます。その結果、プロシージャ名はオーバーロードされます。詳細については、「[プロシージャ名の多重定義](#stored-procedure-overloading-name)」を参照してください。Amazon Redshift では、出力引数に基づくプロシージャのオーバーロードを有効にしません。2 つのプロシージャで名前と入力引数のデータ型を同じにして、出力引数の型を異なるものにすることはできません。

所有者またはスーパーユーザーは、ストアドプロシージャの本文を、同じ署名を使用する新しいものに置き換えることができます。ストアドプロシージャの署名または戻り値の型を変更するには、ストアドプロシージャを削除して再作成します。詳細については、「[DROP PROCEDURE](r_DROP_PROCEDURE.md)」および「[CREATE PROCEDURE](r_CREATE_PROCEDURE.md)」を参照してください。

ストアドプロシージャを実装する前に、その命名規則を考慮することで、競合の可能性や予期しない結果を回避できます。プロシージャ名は多重定義できるため、Amazon Redshift の既存および将来のプロシージャ名と競合する可能性があります。

## プロシージャ名の多重定義
<a name="stored-procedure-overloading-name"></a>

プロシージャは、その名前と署名 (入力引数の数および引数のデータ型) で識別されます。名前が同じでも署名が異なる 2 つのプロシージャは、同じスキーマ内に存在できます。つまり、プロシージャ名は多重定義できます。

プロシージャを実行する際に、クエリエンジンは、指定された引数の数と引数のデータ型に基づいて、呼び出すプロシージャを決定します。多重定義を使用すると、CREATE PROCEDURE コマンドで許可されている制限まで、可変数の引数を使用してプロシージャをシミュレートできます。詳細については、「[CREATE PROCEDURE](r_CREATE_PROCEDURE.md)」を参照してください。

## 名前の競合の回避
<a name="stored-procedure-name-conflicts"></a>

プレフィックス `sp_` を使用してすべてのプロシージャに名前を付けることをお勧めします。Amazon Redshift は、ストアドプロシージャ専用に `sp_` プレフィックスを予約します。プロシージャ名に `sp_` プレフィックスを付けることで、プロシージャ名は Amazon Redshift の既存または将来のプロシージャ名と競合しなくなります。